Just three weeks ago, I was asked to step in for Ted Neward to give a tutorial at Öredev on Effective Enterprise Java. As I did not have time to get the tutorial materials printed, I present them here on the web for the participants and others.
Read more ...
When I write Java-projects that produce web pages, I test on several levels. First, I use Jetty and WebDriver to test the result via http. (WebDriver even lets me test JavaScript!)
But for speed and agility, unit-level tests beat even the fastest integration level tests. Unit tests run much much faster, and lets me pinpoint problems much more accurately. As a general rule: If you introduce a bug, you want a unit test to be the one that sees it first.
Read more ...
What will the daily experience of software development look like, say, five years from now? Have our current processes reached their peak, or will the world continue to change? Alan Kay said “the easiest way to predict the future is to invent it.” Here are some ideas of the future I want to invent: I hope it will be dramatically better than what we currently do.
Read more ...
In my current project, we use Flex as the user interface framework of choice. Flex has some nice features, but it takes a long time to build changes and start up, so it takes a while to validate our changes. Yesterday, we found a problem with one our UI components, and used JUnit to hunt down the same problem all over our code.
Read more ...
Here’s a neat trick if you want set an object in a specific state in a unit test, but you don’t want to violate encapsulation:
Read more ...
This is a test case from my current project:
Scenario: Finish gathering information
Given I have an open case
And the case has a task "gather information from X"
And the case has a task "gather information from Y"
When the user confirms that task "gather information from X" is completed
And the user confirms that task "gather information from Y" is completed
Then the case should generate a new task "evaluate customer standing"
It seems pretty run of the mill. A tester will sit down with a bunch of these and try out the application.
Read more ...
Doing the Code Dojo at Oslo XP meetup last Monday, I realized a new concept that I’ve been using unconsciously for a while: I only add to the structure of my system when I have a test that cannot be satisfied by the current design. The rules of test-driven development tells me to wait to create a more advanced design until I have a reason to do so. And that reason should be a failing test. However, the rules of refactoring require all tests to be green during a refactoring. So the failing test must be Ignored during the refactoring.
Read more ...
Agile development is easy to understand and hard to do. One of the hardest things to do is to base plans and actions on value instead of effort.
An article by Alistair Cockburn includes a story that illustrates the point:
A boy is behind on his German language home work. He now has to read ten stories and answer a set of question for each. He will be graded on the number of correct answers.
Read more ...
I’ve all but stopped using mock objects in my tests. The reason is that mocking have had a detrimental effect on the design of my systems. I’ve often ended up having the mocks trick me into adding a needless layer of indirection that does nothing except delegate to the next layer, just to satisfy the mocks.
Read more ...
The hard choice between duplication, paralysis and chaos
A common programmer credo is “Don’t Repeat Yourself” (Pragmatic Programmer) or “Once and only once” (Extreme Programming). Like all credos, we risk following it even when it is not appropriate.
The larger truth is that we have choice between three evils:
Read more ...