- You are not allowed to write any production code unless it is to make a failing unit test pass.
- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
I wanted to practice TDD and some Java8, so I tried to follow the rules and solve the problem using streams and lambda expressions.
To start with, I wrote the most simple test scenario.
It was straight forward, so once I wrote the code to make it pass, I added more test cases:
Once the code made the tests pass, it was clear that this code needed refactoring.
So I refactored it.
I didn’t want to add the cases where the number is reduced by subtraction like e.g. 4 -> IV, instead I added a new letter to convert 5 -> V.
After having passed this test, I continued by adding more numbers like 6 -> VI, 8 -> VIII…
Before adding the numbers that require subtraction, I decided to test the algorithm with more letters, so I added 10 -> X.
Once the new code made the test pass…
and again it needed refactoring.
So I refactored it by adding an Enum containing letters and decimals numbers like so:
After the Enum was added, it seemed easy to add more numbers, excluding those that require subtraction.
I added roman numerals until thousand (M) and the algorithm was working, so I felt comfortable to add the remaining numbers which require subtraction.
After adding these cases to the Enum, the implementation was working fine.
I am pretty sure, that if I would have tried to solve this problem without following TDD, the result would have been different and probably not so clean.
To follow the steps for solving the kata, have a look at the history commits.
Full source is located on a github repo roman-numerals