TDD and Encapsulation

The type and nature of the tests that you write in TDD helps you to understand how strongly your system is encapsulated.

Everything the system must do, and yet might not, needs a test. Here, “must do” comes from your stakeholders’ requirements, and is therefore connected to business value. The more your tests are about these issues, the clearer your specification will be.

Everything the system must not do, and yet might, needs a test. Here, “might” means that the unwanted behavior is possible, that it cannot not prevented in some way. Anything that the compiler, linker, etc will catch and report is prevented and does not require a test. If such tests were written, it would be impossible for them to fail.

Weak encapsulation allows for more of these negative behaviors to make it into the executable, where tests are needed to raise the alarm. So the more negative tests you need, the less encapsulation you have achieved.

Of course, part of this depends on the technology you use. Languages like Java and C# have constructs like private class members and enforced type-checking, and so more negatives can be stopped by the compiler. JavaScript, and the like, have less of these restrictions and so more protective tests will be required.

This is Scott Bain. Visit us at

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.