This week we got back to realistic programming. After last week’s fibo-emirp numbers (even if there were two almost perfect solutions) I found out that real life problems are somehow closer to the teams’ heart.

This week we had IBAN number checking as a kata (yeah, we are doing such exercises on purpose: I’m planning a great attack on World Bank 🙂 ). In order to check an IBAN number, one has to follow the steps below (note, I am using the following IBAN as test data: “IT60Q0123412345000000753XYZ”, taken from http://www.morfoedro.it/doc.php?n=219&lang=en ):

- An IBAN number is an alphanumeric literal of at least five, at most thirty-four characters
- The alphanumeric string can only contain uppercase letters and digits
- The first two characters have to be LETTERS ( trough which we can identify the country of origin,

, we have Italy)**IT**60Q0123412345000000753XYZ - characters three and four have to be digits (
IT

, we’re doing great)**60**Q0123412345000000753XYZ - the rest of the characters can be either letters or digits
- the first four alphanumeric characters have to be moved to the end of the string (Q0123412345000000753XYZ
**IT60**) - all the letters have to be converted to numbers, following the formula: A=10, B=11, C=12 … (
260123412345000000753333435182960

) - as a last step the following computation has to be carried out; resulting number MODULO 97. If the value of the modulo is 1, then we have a valid IBAN. (*)

(*) A possible way of modulo computation: divide the number into parts of (let’s say) eight digits. Take the modulo of this smaller number and put the result of the next pack of digits. Let us break this numerical string into five parts: 26012341

, 23450000

, 00753333

, 43518296

and 0

. The remainder of the division of 26012341 by 97 is 45. The remainder of the division of **45**23450000 by 97 is 15. The remainder of the division of **15**00753333 by 97 is 82. The remainder of the division of **82**43518296 by 97 is 68. The remainder of the division of **68**0 by 97 is 1. [http://www.morfoedro.it/doc.php?n=219&lang=en]

If you’re curious of my solution, you can find it here: https://github.com/tamasgyorfi/Code-kata—IBAN-numbers

The kata is of two rounds, twenty-five minutes each. The exercise involves a constraint also, namely the one testcase one assert. This was needed because there were many cases when I saw testcases with 5-10 asserts. In my opinion that is not a very good practice. Let’s consider the following situation: there is an algorithm of some kind that checks numbers against some criteria. Let’s say the algorithm is faulty and fails for 1, 11, 111 etc. If there is a single test case that contains a lot of asserts (positives and negatives alternatively) it’s gonna fail for one and the test runner will not go on. Which means that the method will not be checked for 11, 111 etc. So one tries to fix the algorithm for 1, and will not notice the pattern… I personally like to see how many test cases there were, how many of them passed, how many of them failed. I don’t like asserts that are not run at all. Comments on this are welcome.