We've been busy for a couple of weeks now refactoring a fairly complex code base of just under 500 classes. None of us really knew all the details about this part of the system, but we didn't let that stop us of course. After some regrouping/-shuffling/-factoring/*ing, the whole thing built OK and all unit tests were green again. All that was left to do was fix the Fitnesse tests. I remember thinking this should be easy since we had all those green unit test. Evil laughter sounds.
We rely heavily on Fitnesse because it allows us to write specifications for our code in a way that is executable as well as understandable for others. You can even finish test cases before the coding is done so the tests work as part of the definition of done for a user story during a Sprint. The tests helped us to understand what the code was supposed to do, on a much higher level of abstraction than a unit test. This made it easier to find out what should be happening and fix the errors that were introduced by our refactoring. Because the Fitnesse tests make about 20,000 assertions we're pretty confident the code still does what it did before.
Written by
Jan Vermeir
Developing software and infrastructure in teams, doing whatever it takes to get stable, safe and efficient systems in production.
Our Ideas
Explore More Blogs
Test Driven Development (TDD) with dbt: Test First, SQL Later
Test-Driven Development with dbt: Test First, SQL Later If you’ve spent more than three days as an analytics engineer, you’ve probably had...
Dumky de Wilde
Python Mocking, the Sneaky Bits
While trying to mock a function in my python code, I found this excellent blog by Durga Swaroop Perla. The blog shows how to use pytest-mock to...
Jan Vermeir
Contact