I migrated my desktop PC to Windows 7 Professional. I didn’t choose the upgrade path, I install Windows 7 from scratch. So, after installing iTunes I had to register my favoured podcasts again:
.Net
Java
Currently I work in a .Net environment, so the list of .Net podcasts is a bit longer. If you are interested in more Java podcasts, there is a question about that topic on Stackoverflow. The following three podcasts are definitely interesting:
Do you have other interesting podcasts?
When you create your unit tests for a method in the SUT (software under test) you will ask yourself how to structure the code in the test method.
I saw two kind of syntaxes which help to structure the code in a unit test method (well, actually there are at least three, but the third syntax is just chaos, so this is definitely not the way how to do it).
SEVT-Syntax
[TestFixture]
public class ThingTest
{
[Test]
public void TestSomething()
{
// Setup
// Exercise
// Verify
// Teardown
}
}
I found this syntax in the xUnit Test Patterns book by Gerard Meszaros. Obviously this syntax is inspired by classic unit frameworks (like junit or nunit). There is one thing, which could be critical: this syntax could be misused when in the teardown block exist code, which has to run always (in other words, which has to be correctly in teardown-method). But when an assert fails, the teardown block would not be invoked. To prevent this case, you have to do extra effort (try/finally construct).
Gerard Meszaros named this usage of the syntax Four-Phase Test. He also showed, that the last phase (the teardown block) could be done by a teardown-method.
AAA-Syntax
[TestFixture]
public class ThingTest
{
[Test]
public void TestSomething()
{
// Arrange
// Act
// Assert
}
}
This syntax I found on the blog of William Wake and ayende. I prefer this syntax, because it sounds good and therefore I don’t forget it. I like also the words which are more precise and there are no competition with the setup- or teardown-methods. It is also clear where to put the asserts.
Conclusion
The most important thing is that you structure your code in your unit-test. It is also very important that you test only one concern per test method. A syntax helps you to create readable, maintainable and specific (one test-concern per test method) tests.
Currently I’m staying at copenhagen at the GR8Conf (Grooy, Grails and Griffon confernence). In the talk of the day by Guillaume Laforge about DSLs he showed the following code:
class CurrencyAmount {
Number amount
String currency
String toString() { "$amount $currency" }
}
Number.metaClass.getEuros {->
new CurrencyAmount(amount:delegate, currency:"EUR")}
10.euros
//Output: 10 EUR
It is really interesting to see where in the java world the language evolvement happend. It’s a bit similiar (I’m careful here, because I do not know groovy very well) to the extension methods in .Net.
For me groovy and grails are very interesting technologies, so I will stay up to date.
There is a little differences how C# and Java implement the switch-statement. I discovered it when I want to implement a fall through in C#.
In Java it is very simple: just leave the break statement at the end of the case block away.
In C# it doesn’t work like that. There is no implicit fall through (with one exception: The case blocks have to be empty). You have to implement it explicit by add at the end of the case block a goto statement which refer to the case block which should be called.
The advantage of the explicit way is, that a classic mistake couldn’t happened but the disadvantage is that you have to write more code and use the “old” keyword goto (and I thought I wouldn’t see this keyword again…). I found also an explanation for that behaviour on msdn.
Since the 19th february I am Sun certified Java programmer (Standard Edition 6).
