Talk: Easier to change CODE
Talk: Easier to change CODE This is a talk from I T.A.K.E. Unconference 2016, Bucharest. It is a hands-on talk, where I refactor some code live with the help of the audience. Techniques During this…
Talk: Easier to change CODE This is a talk from I T.A.K.E. Unconference 2016, Bucharest. It is a hands-on talk, where I refactor some code live with the help of the audience. Techniques During this…
Talk: Legacy Code is Fear (Łódź, Poland) Legacy code is fear because we fear the unknown. Learn what you need to learn in order to be less scared about legacy code during this talk. This…
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…
Legacy code is fear because we fear the unknown. Learn what you need to learn in order to be less scared about legacy code during this talk. You are a programmer. Someone from the company…
Add feature on legacy code – code cast 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…
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.
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.

Fix bugs on legacy code – code cast 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…
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.
When we need to fix bugs on legacy code, we first need to understand if the described behaviour is in fact a bug or not. For that we can write some characterization tests in order to understand what the system really does. The simplest form of characterization test is a system test. A couple of ideas to start writing the characterization tests are to use the generic approach Part 2 – From Nothing to System Tests and Part 3 – Golden Master. We can generate system tests considering that the System Under Test (SUT) is a black box. You can find more details about how to do that in the blog posts and code casts about the above techniques. But in order to fix bugs on legacy code we need to dive more into the code base. We need to write tests on a smaller scope and we often need to refactor in order to make room for the code changes. Let’s see a technique of fixing a bug in legacy code.
