Say Yes to TDD for QA tests

[ original gist 4 Aug 2013 ~ short reply on LinkedIn, copied for posterity… ]

TDD for integration tests? YES, but for different reasons than “maintenance” or
“acceptance”…

In testing, there is test creation and test maintenance. You have to do both if
you want tests to serve you well. Same for any product or tool.

But if maintaining tests slows you down ~ that is, the product requirements change
so rapidly that keeping tests AND product up to date is a strain ~ then they are
over-designed beyond what you need, and that’s because your product is not well
understood.

You can create an integration test ~ TDD style ~ from the requirements as you
and the team understand them. Such tests don’t need to be comprehensive, more
like sanity checks. Just one or two of these per iteration is enough to surface
the critical misunderstandings early. Then you can integrate the useful parts
into the larger suite.

Same goes for unit tests ~ though in TDD fashion, you lean on them more heavily
to get at fundamentals (design patterns, mocking, speed, etc.). Bigger tests
mean a story’s implications are not well understood ~ “it will take more effort”
is the correct issue when you see this happening ~ “we need to refactor this into
smaller parts” is another correct response.

The goal is not the test suite but a well understood product you can maintain ~
and maintain pace without burning out.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s