A few weeks ago, I had this idea of organizing an in-house self development group. Since then, we have already had three weekly meetings, with a kind of tricky exercise to solve.
When I first started thinking about our first task, I wanted to define a pretty good learning outcome besides of exercising TDD. Let’s get back to this later on (however, it’s not that hard to figure out what it was, given the post title).
I think, the following is a very good exercise (both for coding dojos and other kinds of practicing), so here we go, maybe someday it helps someone. The task is the following:
Given an amount of money expressed in Hungarian Forints and a Hungarian VAT (Value Added Tax) number. Your task is to return the VAT-increased money amount (VAT is 25%), if the supplied VAT number is valid. Hint: The Hungarian VAT number is valid if and only if:
- Its first two characters are “HU”
- the next eight characters are all digits
- Let’s denote the first seven digits by N(1)…N(7), and the last one by C(1); The following equation should hold: S=9*N(1)+7*N(2)+3*N(3)+1*N(4)+9*N(5)+7*N(6)+3*N(7), C(1)=10-S%10; (A valid Hungarian VAT number according to the formula is: HU12345676)
Yeah, this is not a three-weeks-long exercise. Of course not, there is a one hour timebox to solve that. When you are ready, start implementing the second part:
New feature is needed, German VAT numbers should also be accepted. But guess what, Germany applies different VAT percentage (I don’t know what the exact number is, 19% is just ok, I guess) and a different validation algorithm. A German VAT number is valid, if and only if:
- Its first two characters are “DE”
- the next nine characters are all digits
- S=2*((N(I)+S+9)%10+1)%11, C(1)=11-S; (i=1..8, C(1) is the last digit, exactly as discussed above). As test data you can use DE123456788
Again, one hour to solve that. When it’s ready, the third part can be started: refactor your solution to an as flexible design as possible. That, of course can be safely done, as the previous two rounds ensure that unit tests are in place. Any kind of refactoring mistake will be caught by those tests. You have -again- one hour to solve the third part (of course time limits can be adjusted depending on the audience).
We completed the exercise with our TDD group today (the only thing I pointed out throughout the three sessions was the idea of separation of the algorithms). Guess what, by the end of the third session, 80% of the group have implemented the strategy design pattern. And many of them weren’t even aware of it. I guess this is cool; if you read an article or tutorial on a certain pattern, you don’t necessarily get to understand and/or memorize it. But if you implement something, and someone tells you: “you’ve just implemented the X design pattern” that’s something different. Then you can’t forget it, even if you tried.
Mission accomplished, the objective I set (now I can tell it was “(re)discover Strategy GoF design pattern”) was completed successfully.