Plenty of time has passed since the last time I opened The Blog.
The topic of the day is 'how you write code good'. I don't remember times when I had enough time for the unittests. So, i'm trying to figure out several rules for myself to stay when working. Now the following sequence seems to be doing its job:
How this happens now. I want to write a new business-logic method:
- I create a method stub in a (bean). With the name only.
- I think of what should this method get as input, and what should produce in output, in both normal and exceptional cases.
- I modify method to the correct signature.
- Then - i generate javadoc ;). In the javadoc I write down all the thoughts I had when was doint 2. of this list.
- I go to test. And create 1 test class for this method. In this class, I do write one-by-one all the cases (negative and positive) of how it's done.
- Mocking - I'd use it, but yet we have a pretty well-done structure, so I can rely on live objects. Though, I'd try using mockito for the brand new things.
- I run tests - they fail. That's good :)
- I implement method - tetsts should start working. If one of them fails, I need to correct either the tests themselves or the method - depending on what's error.
Posts
1 comment:
I personally try to follow something like this (from top of my head):
1. Write what I need to do on a paper if I feel like.
2. Write high level tests with no any implementation and using non-existing helper methods for testing (so the tests will look like a custom DSL).
3. Write the helpers.
4. Start writing the implementation (at this stage I might get an idea whether it is one method or a number of different classes).
5. If necessary, write more low level tests.
6. Implementation.
7. Red? Go to 6. Green? Go to 8.
8. Refactor implementation and tests.
9. If feature is not finished, go to 1.
Post a Comment