A look into the process of refactoring and TDD

Today i figured i'd show, and talk about the evolution of a feature using TDD and refactoring (but mainly show).

To start, i already had a tested system for adding nodes, which simply set _currentStrength to whatever node was added, but did not yet add the notion concept that these nodes were arranged in a grid, My goal was to add this feature.

Starting off with a few quickfire tests to get the basic concept into place.

 

Blue arrows: order of steps

Squares: Added/changed code.

+: new test case

Notice how by the end of this process i've written 5 separate test cases, and yet the thing still cannot store more than 1 item at a time (_currentStrength is not a collection of any kind), This is a sign to "future me" that this feature still needs to be finished.

This actually makes life a lot easier, since you have very obvious signs of what still needs to be done embedded into the code.

C# also allows you to basically "summarize" the testcases above nicely using it's TestCase attributes

Though i'll probably choose to only refactor into testcases after "working through" the individual tests because it's a pretty helpful guide on where to go next and gives a bit more freedom to change stuff, i might even keep the original testcases around as a "delete > fix" type of reference material.

And finally, after finishing that "one element" feature, 


And some mild refactoring: 

There's that done,

Checking along the class for more open issues, to find this, as another such implicit marker from the past to show that this feature is incomplete(ly tested), so there's that reminder system doing work 😀:

That sign tells me i need to work on the way the Develop function interacts with the growth process.

More tests 

More solutions

a

More refactoring

 

Next up is starting the chemical signalling feature, in order to make EmitChemicals actually do something useful here.

Comments

Popular posts from this blog

Building SIC-1 in VCB Part 1: RAM

Building SIC-1 in VCB Part 3: Fadder and auto-RAM

On the intricacies of affordance-based interfaces in C++