Listen to this post
TDD often uses unit tests to drive behavior into the system. However, sometimes acceptance tests are used to do this. When these are automated, this can give us clues as to how to make our work in TDD more reusable.
Tools like Fit, Specflow, and Cucumber are all designed to parse some non-technical artifact (such as tables, text, and images) and then execute the semantics as tests. These frameworks are designed to look for methods, written by Devs, that can be used to trigger behavior which they then verify. These methods are variously named “Step Definitions,” “Glue Code,” “Binding Methods,” etc.
But there is no reason that unit tests cannot utilize such methods to trigger behavior. If these methods will be needed for acceptance test automation, you can reduce the burden on developers by training them to write their unit tests this way in the first place. If they do this, then when it comes time to automate acceptance tests, their part in the process is already done.
This is because of something we call “test invariance.” No matter how you express the specification of a behavior, that expression should be testable at any level in the system, and with any set of tools, as the expression chosen does not change the meaning of the spec, or the test.