Tag Archives: Document

Document Possible Bugs with Tests – Codecast

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

Code Cast

This is a codecast in Java.

In the previous episodes we reach the moment when we extracted one simple class. We used the The Rule of Three and pure functions. This newly extracted class is covered with characterization tests. Then we wrote some unit tests in the following episode. But some of the behavious seemed strange, and we thought they might be bugs.

Because we are never sure when working on existing code if some behavior is a bug or a feature, we want to document all the suspicious cases. In order to do that, I am presenting three methods: use an annotation, prefix the test, use a different class.

When we document defects with tests it is a good idea to group all the tests documenting possible bugs one after the other. The discussions with the business persons are easier and you do not need to search the next test again and again.

Always discuss with business persons before changing the code. Often one might think they understand what the code does, but the situation if often very different in practice. Think to verify every detail with business analysts before changing the existing code.

Document possible Defects with Tests

Blog post series

This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.

Purpose

When writing unit tests on legacy code, we often discover behaviours of the system that seem wrong. The main rule is: DO NOT change the production code without being absolutely sure that the change does not introduce defects. Instead we need to mark all the tests that characterize a possible defective behaviour. Let’s look at some ways to document possible defects with tests.