TDD and Inflection Points

Software is quite often implemented in the context of reusable frameworks and other preexisting, valuable entities. As our industry matures it becomes increasingly true that we don’t need to re-invent the wheel

For example, if code is written that is required to send data over a TCP-IP connection in, say, C#, the tendency is for the developer to use the built-in Socket class that is part of .Net. Why would a developer create their own such entity? It makes sense to reuse what is well tested and proven over time to be effective.

The problem this causes for TDD is that in order to test drive the code being developed, we’d need to specify that the information sent over the socket was well-formed, that it confirms to the requirements. We could create a loop-back on the network to “catch” the information being sent, but this will tend to produce a test that is too slow to run frequently.

The better solution is to wrap the framework entity in an adapter. This would be mostly just a pass-through, and so it would be simple to create. But it creates an inflection point. Such an adapter can be mocked for testing, and thus eliminate the need to control the real socket.

Avoid direct coupling to reusable entities.

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.