This week I vis­ited Exception Twente, a fun gath­er­ing of people work­ing in the soft­ware industry in my region. One of the talks was on Behaviour-Driven Development (BDD), by Tim Schlechter.

His interest in BDD was sparked by the fact that the Don’t Repeat Yourself prin­ciple (DRY) was not adhered to when cre­at­ing specs. Basically, spe­cific­a­tions are “copied” into func­tional and unit tests. BDD looked like an oppor­tun­ity to dir­ectly relate the tests, and there­fore the code, to the spe­cific­a­tions, min­im­ising duplication.
Continue read­ing

Everyone knows that auto­mated tests are use­ful. When you are just start­ing a new pro­ject, it is easy to include all sorts of auto­mated test­ing dir­ectly from the start. You can take all sorts of things into account: auto­matic unit tests, auto­matic user inter­face tests, or even con­tinu­ous integ­ra­tion with auto­matic tests.

But what if you have an exist­ing code base that you wish to add auto­matic test­ing to? Chances are that you can­not just do extens­ive changes to your cur­rent code base, just to add auto­mated tests. Where to start? My advice: start small.

This art­icle will show you how to add auto­mated unit tests to your jar builds. This is fairly simple, and can be done without mov­ing your entire code base around.

Continue read­ing