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 ...
Back to:
www.javaworld.com/javaworld/jw-03-2009/jw-03-lamport-otp.html.
I found it a little hard to understand the underlying security aspects. Is the security of the algorithm based on the fact that the successor-function F is hard to reverse? So that if
A = F(B)
Then it's hard to reverse F? So that knowing A and F will not help you find B?
Secondly, is it correct that the algorithm is insufficient to establish trust? It merely verifying that a visitor is a returning user.
Finally: Is there a common way to handle it if the client runs out of keys?
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 ...
The following is a trick I don’t use very often, but when I do need it, it comes in very handy. It’s a trick that many developers aren’t aware of, even though it’s been possible to do with JUnit at least since version 3.
Sometimes you want to have a lot of tests that are almost the same, but that contain different arguments. For example, for a yahtzee calculator, you might want to have the following tests:
Read more ...
Unstructured picture
Read more ...
“The service went down because another service running on the same application server went down.” “You can’t use the improved version of your programming language because you’re running on the same application server as some old applications.” “We can’t help you deploy your application on the application server, because we’re busy with some other application.”
If you’ve ever heard any of these statements, you’ve been victim to the accidental complexity of the application server.
Read more ...
Have you ever looked at a list of compiler warnings the length of an essay on bad coding and thought to yourself: “You know, I really should do something about that… but I don’t have time just now”? On the other hand, have you ever looked at a lone warning that just appeared in a compilation and just fixed it?
Read more ...