Thursday, November 24, 2011

Programming: Putting all of the Pieces together (Part 3)

Testing the individual units of the code is great for making sure each unit works.  Integration testing is fantastic for making sure the code fits together as intended.  What about testing the interface from the users prospective?

It all starts with plan, when I was a developer at the library we spent over a year combining 4 disparate ticket tracking and inventory systems into a single system that could link library hardware to the request for its purchase, any trouble tickets, etc.  As we were finishing the project our boss asked for a test document.  When complete it was a hundred and fourteen pages complete with step by step tests to be performed from the user interface.  Running through every page would take us about two to three hours.

A few years older and a few years smarter and I still make my team write those test plans.  However, today I'm making them create parallel selenium tests for every item in the document.  The current project is around 50 pages and the tests take 5 minutes, on slow.  The best part about this, selenium doesn't get bored and skip tests.  I don't know how many times, my own boredom caused me to miss an error in a function that I hadn't anticipated would be affected by my change.

So at this point I have tons of tests being generated.  I'm working on changing the workflow of my team so that they analyze the problem, start a new branch, build tests, code and comment, run tests, then push to our main branch.  They are starting to get better, but how do I take this from "you should do this" to "this happens every time". . .

No comments: