A recent fun exercise has been to think about what is so magical about the way we test…

and in a typical campy fashion, I conjured up several incantations of the top list of things that we have done in order to evolve our testing to prepare it for the open.  It has been an interesting journey so far, trying to defend actions that I believe are absolutely necessary, to others who have not spent much time thinking about this topic.

More on this to follow, but here is a little teaser…  to cast this spell out upon the test code repository, ‘abra cadaver’, identifies the dead tests, those tests that continue to run, despite not having unearthed any new defect in years.  This spell renders all who would argue for keeping stale tests silent.  Let’s take a peek at this and many more spells and charms that can make a small test team a mighty force…

As we review the tools and processes we use to manage the large build and test system for our Java products, one observation stands out.  We want things to be simple, but over the course of a decade, more and more custom tooling was written to make the builds more flexible.  A gnarly tangle of scripts sits taunting us…  “just try and fix us”.

Captain’s log:

As we embark on the journey to simplify, heading into uncharted territory, full of trepidation, a solemn quiet settles over us…  if we can’t make it simple to test our products, we will perish.

Most definitely an over dramatization of our 2016 goals, but a fun way to think about the work…  do or die.  Instead of “fixing” the gnarly scripts, opt to throw them away altogether.  Throw out some popular convenience features and tools in the process, because to keep them as they are means continued high maintenance costs in the future.  We will come at the problem by stripping away everything and then adding in necessities.  The claim is that it is far better to have simplicity (builds that anyone can run, tests that everyone can triage and re-run, etc), than have flexibility that only benefits a small portion of the team.