Enforcing Test Driven Development into an Existing Project

In an earlier post I wrote about my observations of a book I have recently read called ‘Test Driven Development: By Examples’ by Kent Beck. The book talks about Test-Driven Development (TDD) and how to apply it practically. From this I wanted to get going with the concept as quickly as possible but without having to make an entirely new project. 

I started to think about how I could apply the practices taught into an existing node module I have written - and blog about too often - hosted on npm. 

In the chapter “How do you switch to TDD midstream” Kent describes how you might transition into using TDD and the issues that might rise from doing so. I have taken the liberty of summarising from my own perspective and will discuss how I implemented it into my latest football simulation engine code (blog). 

After reading TDD and considering its application, there were 4 main factors (tips) for enforcing TDD in existing projects:

·     Test the requirements, not the code

·     Start with new features/bugs

·     Refactor code with testing in mind

·     Ignore working code

As I opened the code and assessed my kingdom the extent of the problem became apparent. There were no tests, but the project was thousands of lines of code, had 3 main exported functions and around 50 functions throughout with no test data or examples to be used by the end user.

Kent says in his book ‘The biggest problem is that code that isn't written with tests in mind typically isn't very testable’. Which happened to be my first thought as I dug into the large functions I had made. Where do I start? I began to write a list of what of the different parts and split them into a simple table with the headers Test, Ignore, Refactor - keeping in mind “What you don't do is go write tests for the whole thing and refactor the whole thing”. I wanted to decide what could be tested, what should be tested and what shouldn’t be tested. 

Test: A new test should be written to test the functionality I expected from the requirements.

Ignore: Large bulky functions which called other functions and needed a lot of intense work to make it test ready.

Refactor: Code that could be refactored to make it testable.

Test	Ignore	Refactor
Input Validation	Move Ball	Set Freekick
Closest Player to Ball	Find Possible Actions	Set Corner
Closest Player to Position	Resolve Ball Movement	Set Penalty
Check Offside	Decide Movement	Formation Check
Split Number into N		Shot Made

The first and easiest on the list was Input Validation, so I began to write the first test for when a games initiation input JSON was validated. The first test was simply that we got an object back. Success! This led to a quick imitation for the other two main functions of the project; start second half and play iteration.

 I then wrote some negative test cases by purposely inserting input data that shouldn’t be valid. Importantly, the question I asked myself was, what tests cases were valid based on the requirements and not the code that had already been written. This caught a number of validations I was not already catching in the validation functions.

An example was when I removed the ball from the play iteration function input and the test failed - by not failing. How can a football simulation work without the ball? This is why Tip 1 is: Test the requirements, not the code

mocha.it('playIteration no ball with team',async() =>{

      letprovidedItJson= './test/input/badInput/noBallWithTeam.json'

      try{

        letoutputIteration= awaitvalidation.playIteration(providedItJson)

        expect(outputIteration).to.be.an('Error')

      } catch(err) {

        expect(err).to.be.an('Error')

        letexpectedOutput= 'Provide: position,withPlayer,Player,withTeam,direction,ballOverIterations'

        expect(err.toString()).to.have.string(expectedOutput)

      }

    })

Having fleshed out all the required checks on the input validation for the three main functions (using mainly negatives) I felt assured that the code would be able to tell the user when their input was wrong, and more specifically - why it was wrong. 

At the same time, I was doing some house cleaning of the code and some general refactoring. Additionally, a few bugs were raised in the GitHub repository by users of the module. 

Some related to queries on parameter names, others were refactoring suggestions, but some referenced specific issues being seen in the code. Players were getting stuck, the closest player to a position was incorrectly assigned and the ball was moving too quickly. Investigations also caused me to raise my own issues which I could also test. 

Bugs and new features for existing code mean that the requirements are set out before any changes or new code is written. The code should behave in a certain way and currently doesn’t. From this you can essentially work on a blank canvas in terms of writing tests (using TDD). Tip 2: Start with new features/bugs. 

For the bug of not calculating closestPlayerToBall, there was no way to validate the issue because there were no tests. I started to write a test case by placing players on the ‘pitch’ where I knew which player was closest to a position or the ball. The test then is simple - does the function, when given the input data, correctly identify which player is closest to the ball? 

Once we run the first test - and potentially get a FAIL, we can start TDD from the beginning. What is the simplest thing we can do to the existing code to make it PASS? By then following the TDD method the code was altered until it passed the conditions successfully. At which point we had a passing test for the closest player using TDD as the method. 

Writing tests for the whole project in this way and then ensuring they PASS would conform the project to TDD and I believe would reduce the number of small bugs that end up being raised in the Github repository. However, it is a long process and would take up a lot of productive time, when there are other big fixes and new features to address.

Another major issue was the way that shots are made. A player makes a shot, a bunch of logic plays out and then either the goalkeeper has the ball or it’s a goal kick. All without so much as a little ball or player movement. This leads to the next step in the introduction of TDD - Tip 3 - Refactor code with testing in mind.

The shot made function had been several hundred lines long and included a variety of methods within. This doesn’t test easily. As code was edited for v2.1.2 I started to make changes to make it as simple as possible, abstracting out functionality into smaller functions and thus making each component easier to test using TDD. 

It’s important to remember that this isn’t the time for TDD yet. TDD is the process and steps for creating code that passes the test. Following the rule of only writing tests for new features or bugs this extraction of logic into smaller forms sets us up for TDD without investing unproductive time into its making.

In the list I created at the start there appears to be no real difference between some of the functions in the ignore and the refactor slots. There are a number of reasons to ignore specific functions. For example;

-      The function is very large and/or complex

-      The function cannot easily be split into smaller functions

-      The tests would take a long time to write

-      The function isn’t broken

For example, in FootballSimulationEngine - Decide Movement cannot easily be split into smaller functions and is very large, Find Possible Actions would both take a long time to write tests for (because of its complicated logic) but also the function simply isn’t broken. Resolve Ball Movement requires a lot of random number generation and mathematics which makes it difficult to test and Move Ball isn’t broken either. 

This analysis focuses heavily on the code I have written and not the requirement which goes against tip 1, but this is mainly because of Tip 4 - Ignore working code. If it isn’t broken, don’t fix it.

Put in another way, it has taken two years (more or less) to get the code to where it is today, with time etched away from weekends and evenings. To use TDD in the whole project would mean to essentially start from scratch. In his book, Kent states “Spending money without making it is generally speaking not a sustainable process.” And as a subscriber to the statement ‘time is money’ it seems more responsible and a better use of time to slowly introduce TDD as bugs appear and are fixed, or new features are included. 

By v2.1.2 the list looked a big better. In future editions I can see some of the ‘Ignore’ items moving into the ‘refactor’ bracket, the ‘refactor’ tasks moving into the ‘test’ section and removing the ‘test’ tasks as tests are completed for them. See below for the table as of the commit of v2.1.2.

Test	Ignore	Refactor
Input Validation	Move Ball	Set Freekick
Closest Player to Ball	Find Possible Actions	Set Corner
Closest Player to Position	Resolve Ball Movement	Set Penalty
Check Offside	Decide Movement	Formation Check
Split Number into N		Shot Made
Shot Made

 If you want to see a wider use of TDD in the FootballSimulationEngine code I’d love to see more enhancements raised in the Github repo. Thanks for reading. 

Observations of Test Driven Development

I was recently recommended the book ‘Test Driven Development: By Examples’ by Kent Beck in order to evaluate the methods engaged when dealing with coding challenges and working methods. Below are my observations on what Test-Driven Development is, its impact on real-life projects and how it might change the way we work. 

https://www.oreilly.com/library/view/test-driven-development/0321146530/

Test Driven Development (TDD) is a practice for creating clear, simple and defect/bug free code by writing tests first and then building code that makes the test pass. Tests are written one at a time in order to create the minimum required code but also to improve the reuse of code as thought is put into passing the test and just the one new test being introduced at a time.

In a typical TDD cycle a new test is added, all tests are run (with the new test either passing or failing), a change is made if tests fail, test is run in order to create success before finally refactoring to remove duplication. In this was a series of new tests can be created whilst constantly reusing existing functionality and staying focused on the issue at hand.

The process challenges the way development methods are normally implemented and thought about because of the subtle difference between writing tests for code and writing tests for requirements and writing code that causes the test to pass. It should be noted that TDD is not a replacement for performance, stress or usability testing. 

My first observation was that TDD is a slight move away from the Agile approaches I have seen on real-life Projects, in that many Agile projects have taken too literally the idea that documentation is secondary to building code, which isn’t helped by ‘Agile’ change process which means designs can quickly become obsolete. TDD is reliant on good documentation in order for tests to be written that achieve the goals and objectives of the project. The ‘How’ is agnostic but the ‘What’ isn’t.

An additional benefit in the TDD world is that the tests themselves describe the code better than standard documentation can, and it is factored into the test development. As code changes and test changes we find that the documentation the tests provides is also updated meaning it won’t go out of date.

Another observation when thinking about implementing TDD into real-life projects is that it really will work, especially with Agile as it allows projects to clearly define goals. This can be used to reduce scope creep and to ensure completion falls under the test definition. 

The book itself shows the low-level detail of splitting projects into small bite-size chunks using python and Java as examples. Specifically, it shows very small steps undertaken in order to demonstrate the method. This does help and (sorry to harp on...) works with Agile because tasks can be split into Sprint cycles but also because it makes the work specific and easier to understand, additionally whilst a large task as a whole might be difficult to implement, it may become easier when smaller parts of it have already been completed. Think of it like inserting libraries into a project where you create the small independent libraries yourself before merging them to make the end project.

From this perspective, nobody will ever go quite as slowly as the book shows the implementation, at least, not whilst also delivering at the pace that generates income or delivers targets - which is recognized in the book:

   “TDD is not about taking teeny-tiny steps, it's about being able to take teeny-tiny steps”

   “Am I recommending that you actually work this way? No. I'm recommending that you be able to work this way”

As with every method, the solution should always begin with best intentions. It will perform everything it is intended to, following good practices and standards. The difference is that as tests are being written before the work begins, both the tests and code are evolving at the same time whilst being refactored to remove duplication and obsolete code. In theory, we get quickly to the simplest solution, an increased reuse of code and tests that pass.

In real-life projects prolifically tend to overrun or removes scope or cost more money. Time, Scope and Cost. Unfortunately, as development becomes more rapid towards target deadlines so too does the elimination of anything not very importantwhich often means tests. Not all tests, but coverage gets overlooked as an ‘easy’ thing to disregard. If the happy path is working, we had better move on to the next important thing. 

The book asserts how there is a correlation between fatigue and judgement as well as between stress and testing in that increased stress reduces the number of tests. Anecdotally, when I have worked with development teams at high octanes over short periods of time - including evenings and weekends - I find it takes that extra conversation for things to be understood, or that extra bit of time to find and understand a bug.

The theory is that by applying TDD, tests won’t be disregarded as Time and Cost begin to cut into Scope. Instead, tests will catch the issues regardless of the stress, fatigue or reduced judgement project deadlines bring.

The additional value is that once the tests are written, they become the regression tests for all new feature inclusions which keeps the project on track despite potential side effects of changes in other parts of the environment. 

Throughout reading the book I found I was constantly thinking how TDD could be applied to my existing projects: Chatbot, FootballSimulation, API Development and more. The persistent thought was that actually testing a lot of real-life systems won’t be easy, especially past the unit test level where functional and integration tests come into place. 

Take for example a chatbot, how do I test a chatbots conversation has the relevant output from each input when a good chatbot will have lots of different outputs. How can I use TDD to get conversation direction whilst making the chatbot seamless?

In another example, how might I use TDD in a wider project such as during the deployment of an API Gateway? Do I test that I can make calls? that I can deploy policies? Is this even a valid scenario to use TDD? 

Part of the solution is in the use of mocking to mock parts of the flow. For chatbots there is an existing repository for ‘botkit’ https://github.com/gratifyguy/botkit-mockas an example of how mocks can be used in TDD. This does raise other issues in that creating good and effective mocking can be difficult, especially the more complicated the project and potential outputs become.

There are other concerns that can be raised such as knowing when to stop. In the past there have been test suites which have tested every hour of the day for a year. It took a long time to run as part of the suite, used up vital memory and added very little to the overall code of the project we were running. It’s important to know when to stop making testsby covering a wide range of scenario e.g. edge cases without testing every scenario.

My final thought is that TDD will require a lot of teamwork. Someone working alone to perform TDD will soon find themselves swimming upstream against a river flowing ever faster. The team would need to collectively agree the approach from the start with measures in place to ensure continued acceptance of the approach. There will also be a need for continued understanding of changes to the requirements as they are made and confirmed. 

An architect meeting leads to a change of requirements e.g. all traffic must be secured through mutual authentication. Tickets are raised, developers are informed, and tests updated to reflect the new requirement. 

In current projects, the tickets may become stuck in the backlog, it might be implemented only in some environments or the tests not updated due to time constraints. However, with test-driven development the tests are updated first, and all environments fail until changes are made to match.

There are obviously massive benefits to TDD in order to turn the approaches we make to projects on its head. Bringing tests to the forefront makes sense, gives a clear end goal to reach, gives a clear definition of done, becomes its own documentation and can be as specific or as loose as a project desires in terms of tracking implementation. 

I can see clear benefits in programming, API development and even in wider integration projects. I look forward to using it soon. I would love to hear where you have implemented TDD, the pros and cons and how I might avoid falling into common gotcha’s. 

You can email me here