Test tastes

it’s been since a while our team decided to discuss different approaches we’re using on testing – it’s one of the actions voted on last team retrospective. we’re growig as a team, (great) new team mates recently joined, and everyone it bringing more experience and ideas. and testing is one of the most interesting item everyone has in his own agile “toolbox”.

yesterday Matteo started discussing, posting his ideas on acceptance and integration tests. he has done a great work, trying to explain his point of view while showing other’s, such as Shore’s. and me, i put a note on my “to-blog list” long ago, so it’s time to talk a little about.

tests are artifacts, testing is an activity. the funny thing is that you can use tests to actually do something completely different from testing. it’s something as clear as understand which role the T plays in Test-Driven Development: use tests to drive your development. time for some examples.

1. unit-tests are for designing. you write a unit test before coding, you use a red bar to clarify ideas on how thing should go, and you code until the bar becomes green. then, you use a green bar to safely check you’re not changing behaviours, while refactoring – improving the design.

2. integration-tests are for testing. ok, that’s interesting. unit-level design is great, but it’s not the whole story. we want to be sure assumptions we did really stands, both inter-connecting with external systems and putting “our” pieces together. it’s really hugged with architecture, so that modular architectures better help testing on different scales (such as one-side at a time, when using an hexagonal architecture).

3. acceptance tests are for understading the domain. in other words, requirements: business rules, constraints and flows. ATs are great to explain generic rules using examples. being automatic, they’re also sort of regression tests. again, modular architectures let ATs be independent, self-contained within the domain layer.

maybe in a past life i was a tester, because i still miss something. i find myself having need of one more test, just one, running from UI deep through the persistence. Matteo calls it an end-to-end test, Miško use the term scenario test, for me it’s just another integration test (ok, they’re twins separated at birth).

call it as you like it. by the way, having a look in our last codebases, i see we had few ways of testing the application when connecting to a subset of external subsystems:

• an acceptance test, when rules were focused on presentation
• an integration test for the topmost side of the application, such as the Controller
• an integration test through HTTP, for web applications

that’s how it goes. i’ll really appreciate some feedback on this. so, how do your tests taste?