Rob Smyth

Thursday 11 June 2009

Componentalization Can Be An Enabler For Automated Testing

While working on componentalizing a project (think Domain Driven Design) I have become aware that componentalization may reduce reliance on User Acceptance Testing (UATs) of the application to something simpler and lighter kinda like integration tests. Thing is that these tests are not quite UATs nor integration tests so I've found I need another name to enable effective focus and conversation. The name I'm currently using is 'Component Tests'.

Here is the thing ... you could say that the user of a component, via its API, is a different user. In this case a developer or team. So, component tests are UATs. Sure, but this language looses the focus that UATs have given us of creating automated test as close to the real thing (mouse clicking a button) as possible. Thing is that this makes UATs inherently slow and difficult to test all the corner cases. For example, what if the USB memory stick fails after the user clicks the 'Do It' button but before the save is completed? Hard from a UI level. But if the UI code is moved to its own component and the 'do it' logic in another domain component then this testing is on the domain component via its API. Not hard.

So component tests differ is difficulty, speed, and only the UATs actually test the final functionality. Whenever developers use tests at code level the question is 'how can I know this is the functionality used in the product?'. By componentalizing the products code this risk is greatly mitigated giving the end customer confidence. He/she can believe that the component tests do test the functionality used in the product as the component is clearly identified. A user database component is more likely to provide the functionality of adding a user than the product help framework component.

Critically a component must provide encapsulation, typical via an API. The API is the line of demarcation defining it from integration or unit tests.

The potential advantages are:
  • Simpler to test corner cases, more unit test like. An enabler for better tests.
  • Test run faster. Essential for Continuous Integration (CI) and a cost saving for any project.
  • Componentalization means fast developer and build box compile times.

1 comment:

Duncan Bayne said...

Am I right in assuming that the type of components you're talking about are primarily UI subcomponents of an existing system?

So, if I have this right, you test the UI component in isolation, then do the minimum of integration testing with the full system, just to make sure it holds together once in place?