Tag Archives: Bug

Talk: Java User Group Łódź – Legacy Code is Fear

Talk: Legacy Code is Fear (Łódź, Poland)

This is a talk from last year, before Global Day of Coderetreat Lodz.

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 comes with an idea to add a feature and they are sure this new feature is very easy to add. And it should be. But the code is old. The code is a mess. Nobody in the firm knows any more that part of the system. You need to change that ugly piece of code. You are afraid that you might introduce defects. Legacy code is fear.

 

Here are the slides for the talk Legacy Code is Fear:

Legacy Coderetreat: Episode 13 – Document Possible Bugs with Tests – Code Cast

Document Possible Bugs with Tests – 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 see more sessions about legacy code.

Code Cast

This is a code cast 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 behaviours seemed strange, and we thought they might be bugs.

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

Bug or feature? Check out the code cast to see all of them in action.

Read here more about this concept in my blog post.

Talk: Agile Lean Europe 2014 – Legacy Code is Fear

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 comes with an idea to add a feature and they are sure this new feature is very easy to add. And it should be. But the code is old. The code is a mess. Nobody in the firm knows any more that part of the system. You need to change that ugly piece of code. You are afraid that you might introduce defects. Legacy code is fear.

 

Here are the slides for the talk Legacy Code is Fear:

Legacy Coderetreat: Part 14 – Document possible Defects with tests

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.

Document Possible Defects with Tests

Document Possible Defects with Tests

Read More →

Legacy Coderetreat: Episode 3 – Fix bugs on Legacy Code – Code Cast

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 see more sessions about legacy code.

Code Cast

This is a code cast in Java. I have a bug report and I need to fix bugs on legacy code. I start by writing characterization test on the system level and then I dive into the code with writing a unit test. See more about the technique in the blog post Fix a Bug on Legacy Code.

 

Legacy Coderetreat: Part 4 – Fix bugs on Legacy Code

Fix bugs on legacy code

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 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.

Fix bugs on legacy code

Fix bugs on legacy code

Read More →