I am working on a project, both to develop a little widget – a calculator to support my weightlifting exercise – and to do it and document it a RIGHT WAY, so that I might later turn that work into a book or a vlog series or whatever.

Anyhow, while documenting the setup (in my project, I want to do Unit Tests and I want to code it with the Test Driven Development methodology), I wrote a bit about the history of development methodologies (in my experience and as I see it), which I thought it would make sense to share here.

To whit:

Once development of this project goes ahead in earnest, I want to implement it with Test Driven Development, which changes the typical development model. The typical one has us write code to do things, try to anticicpate use and misuse cases, and turn the code over to a tester, who tries to anticipate more cases where the code might be broken or vulnerable, where the coder designed the code to work as intended, but didn’t quite get it right. This process usually works but it depends on the quality and experience of the coder, as well as that of the tester(s). Also it relies on “many eyes”. Most development shops have many coders and many testers, so the hope is that potential problems will be noticed and addressed during many rounds of reviews.

One way that traditional development has tried to address the risk of this approach not working (not catching and fixing bugs and other structural issues with the code) is by putting some of the responsibility for testing on developers. This is called Unit Testing, and it relies on the idea that since the developers know how the code should work, they are the most qualified to write the unit tests. So once we create code, we write more code to test it and its assumptions and modules and when we promote the code to test, we hand over the unit tests we wrote to the testers. To help them create comprehensive testing suites. It works better than the traditional approach which is a bit more haphazard.

But then a few years ago, along with pair programming, shorter coding and review cycles, more meetings, other agile methodologies, all designed to make coding easier and easier to review and easier to notice problems with, came Test Driven Development, which I think is an important change in the methodology. Because in TDD, you start by writing testing code. You write the unit tests BEFORE you write the code, and it helps focus the mind on the task at hand. How is the code going to work? Write the tests for that first, and then write the code that makes it happen.

I like the approach because it helps focus on what should go right and what might go wrong, and it also helps build tests into the code writing process, which can help with automation.

Automation is another thing I like. I want to set up the development pipeline so that when I write code, I can see that it worked, and with a very few commands (probably scripted down to one command if possible) I can promote it to the test environment, and then to production, assuming tests pass. All this is accomplished with Automation (one kind of that is CI, or Continuous Integration – likely more about that later).

So anyway, I will try to code with TDD within Python and Passenger, so I can run unit tests locally before I promote it to the Regression/User Acceptance Test environment, and then to Production, upon working to my satisfaction (however I end up determining that).