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

Post a Comment

Popular posts from this blog

Building SIC-1 in VCB Part 1: RAM

Image
 So i've started a (hopefully) short, and fun side-project again. I'm going to try to emulate the SIC-1 CPU within Virtual circuit board. The SIC-1 CPU is an 8 bit CPU with 256 bytes of addressable RAM i just realized i'm currently making it 256 bits but i'll fix that later (incorrect, turns out i was working on 8*8 bytes) And a single instruction: SUBLEQ A, B, [C] it's a S ingle I nstruction C omputer that should be relatively simple to emulate. As an added challenge, however, i'm also limited to using a Universal gate  to do so,  A universal gate, then, is able to "emulate" other gates, these are the NAND and NOR gates. I've chosen to use the NAND gate, Here's a comparison with their "standard" gates I then added some more designs that might come in handy, a pulse-former seemed useful, and i needed some way to delay signals, an R/S latch also seemed like it'd be needed for RAM, and i also added in a D-flip flop and a manual cloc
Read more

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

Image
Well that's a rather obscure title, isn't it, and it'll require some explanation about some non-standard C++ structures i've been building at work. First, i've done a little bit of work in the GO programming language, and i really enjoyed the mechanics of it's non-inheriting interface polymorphism (i've called them affordance-based interfaces) Next, i found this talk explaining how to do type erasure in C++ in order to essentially emulate these affordance-based interfaces: I wrote a prototype of this system such that i could make a set of affordance classes that describe a specific member function, and might serve as a "delegate" for that function, and an interface class that could combine several of these affordance classes into a single type-erasing interface. This part actually uses a bit of "regular" polymorphism to attain it's goal, but since i've written macros that generate all the required code for you, you can effec
Read more

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

Image
 Last time i finished the RAM, an early design for registers and did some initial trial and error with reading data from RAM via registers Next i began some early ALU work, starting from the "traditional" full-adder i made a while back I translated it into a NAND-only version,  which, after some compression, ended up being the exact same size as the original so i could easily hook it into the same test rig Then i started working on automating the RAM read/write cycle, so i could write with registers G/H and read with F/H (H will become the program counter register) This process was somewhat painful since the RAM read signal is just barely long enough to fully store the data, so the write line has to be active before the data arrives, but stop on the same tick that the data line turns off so there's still some leftover wiring from when i tried to have it re-write its own data (which doesn't work since hysteresis can't easily set its own data when the circuit turns
Read more