This text may seem to re-invent the wheel. It was first published within company’s intranet to evangelize and tutor junior programists. That’s why :)

Testing is hard. Making it in an efficient way is even harder. Legions of experienced functional and technical people spent man-years on finding out the best approach and (IMHO) they didn’t come up with anything special - what we usually do is: create cycles, scenarios and scripts based on functional requirements, maintain them all during project life-time and execute scripts manually as needed. Usually the testers we provide are the gap-fillers - they know what to focus on, which part should be re-tested after particular functional changes, etc. That makes testing less automate and more dependable on people who perform them. So, if it works, why should we change it? What are the problems with the classic approach?

  1. Usually test scripts are poorly categorized and grouped, so it’s not obvious what should be retested after changing part of given module.
  2. Test scripts are executed manually and (in theory) consecutive changes in particular module should be followed by series of re-testing.
  3. Test scripts are maintained as long as main project is up. As soon as basic maintenance starts, every regression test appears to be a problem.
  4. We perform testing on the level of UI only, so if we want to test some “guts” we usually need full End-to-End testing.
  5. Efficient test data management requires a lot of cross-system knowledge and gets very complex.
  6. Sometimes testing even small and simple routines requires running heavy processing (like end-of-day) and that doesn’t help in performing quick re-tests
… and many, many more.

The one who follows what’s hot and trendy should immediately answer - go unit testing! It’s seems an obvious choice, but we usually don’t do it. Why? Because it’s not in the traditional approach?

Project managers don’t believe in unit tests due to various reasons:
  1. Developers don’t know how to make really useful unit tests, so they usually get bored very quickly and morale drops rapidly (together with programming efficiency).
  2. "Hey we’re paid for delivering, so let’s focus on coding and we’ll fix what’s to be fixed later!"
  3. Every test needs to load plenty of data and wipe database afterwards, so running tests takes a lot of time
  4. "We had to overhaul this accounting module, so we’d need to re-write all unit tests and we don’t have time for that!"
  5. "Sure, they write tests, but as I’m not that much into code, how should I know if running them is enough to prove code as correct? I have to maintain and run scripts anyway, so unit tests are redundant!"
… and many, many more.
 
This is just a short blog entry, not a book about testing, so I’m not going to address all of that, but from my perspective:
  1. If you can’t write tests efficiently, it’s probably because you have a faulty application architecture (95%).
  2. If you start coding with creating interfaces (functional ones) and composing tests on the top of them, you can easily validate your developer’s work without digging into the details. It’s extremely convenient and useful.
  3. If your developers don’t get it that tests are here to save their … bottoms, they surely do not know how to make the tests.
  4. Tests are useless without proper data approach and if you do it right, you don’t have to care about end-to-end on the level of unit tests (try mocking, I’ll write more about that below).
Just one small example - we had a short (~350 MD of development) but very challenging project (I’d call it R&D one). To make it succeed, we had to create about 1000 unit tests and IMHO we were at least another 1000 tests short. Without unit testing, we’d fail after a month or two without possibility to move further. We had no external testers, no scripts, no functional people to do regression stuff. All the knowledge was coded and maintained in categorized and well described (but short and clean) unit tests. No-one will convince me that skipping tests makes things cheaper, easier or more convenient to maintain.
 
For those who’d like to know more, few links to start with:
  1. Kent Beck’s book about TDD: (http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530/ref=sr_1_1?ie=UTF8&qid=1324993911&sr=8-1)
  2. Website of Typemock - those people are among the best unit testing experts worldwide (http://www.typemock.com/)
  3. Book written by Typemock’s chief architect - Roy Osherove (http://www.amazon.com/Art-Unit-Testing-Examples-Net/dp/1933988274/ref=pd_sim_b_4)
Why did I decide to write about something that low-level? I’ve recently started to use Typemock’s Isolator - a library for mocking, great utility to separate your tests’ contexts (make it easier to test only part of solution without the need to load tons of data and configuration). I have an experience with similar tools (Moq), but now, with Isolator I see no excuse for avoiding creating unit tests. You can expect me writing more about mocking and Isolator soon.
 
Unit tests done well = Highest Quality. No Bullshit.
Share this post