Test Suites as an Upstart Tool


View My GitHub Profile

Congrats on your launch. Your product is awesome. Everyone wants to use it but they want features and you launched a really really “M” MVP. Awesome. You stayed focussed, wrote great code, and got it out there but you need horsepower behind the keyboard to deliver customer value, keep your investors happy, and grow to be the next awesome four letters on NASDAQ. So you go to your local user’s group and find a few great talented and diverse developers who are excited by your product and your team’s culture of rapid delivery of high-quality code. What can you do to ensure that on day zero they can be delivering code that works and is (relatively) free of regressions? The world may never know…

There is currently a great deal of debate about the various merits of testing, Test-Driven Development and/or Design, isolated unit vs. integration tests, and any number of other related subjects. There is no doubt in my mind that testing is one of the most important things you can do for your development process, for your customers, and for your team. There is an additional benefit of having a clear, fast, and easy to run test-suite that exercises your entire system from top-to-bottom. It makes adding new team members easier by allowing them to immediately add value to the system and know that they haven’t broken something.

I have worked with a team who wrote extremely impressive software. The scale of the project was impressive in every regard. The technical feat they accomplished was staggering and as a side effect they did not expect new developers to understand it well enough to produce anything of value for a long time. By a “long time” I don’t mean a couple of days, or a week, but maybe weeks or a month.

Part of the problem was that testing the system as a whole was actually difficult. Some core components had tests, others did not. Many languages were in play for very pragmatic (and appropriate) reasons. The team was under a great deal of pressure to deliver quickly and as often happens in that situation, particularly when developers do not come from a culture of testing, tests were simply never written.

I was able to add value quickly by picking off tiny pieces of functionality, entirely skipping tests, and getting some code into production at our next release. But this was not the win the team thought it was. Future “small” features introduced regressions and outright bugs. Other bugs that came up were easy to blame on changes made by the new guy because they were in the same module when in fact they were long-extant bugs that had never been revealed until a user wanted to try the new feature.

What can we learn from this song of gloom and software doom? What would have allowed a new developer, or a person who has mostly worked on one or two components, to contribute freely anywhere in the project? A comprehensive unit-test suite for each component is a great start, and is often overlooked in a team’s process.

Consider the situation where a core back-end component requires a modification. This is radically different than bolting entirely new functionality to an application. In the latter case there are few interactions within the system to consider, but rather how to expose the new feature to users. In the case of core components there is very often a complicated interaction between that component and other components both on the front and back-end. Those interactions are likely well understood by the original author, and maybe even other team members, but are tribal knowledge.

Tribal knowledge itself is not a bad thing but codifying it in a way which can be easily assimilated by new members of the tribe is key. GitHub pages, wikis, and other documentation have their value but it is extremely easy to not read, let them get out of date, and simply be ignored. Test suites serve the tribe in a number of ways:

Taking the time to flesh out your tribe’s knowledge about the system up front, or as early as is possible, will pay dividends as you hire. Your new team-members will feel confident in their contributions and empowered to work where they can provide the most value without fear. This is particularly valuable when one of your original core members is out for their first vacation in years, or have their first-born, or are just exhausted and need a day off. The newer members of the team will happily step up without wanting to call their cells when things break horribly.

How does your team prepare to bring on new team-members and make them productive on day zero?

Have something to contribute? Open an Issue on Github and let's have a chat!