Exploring the Subtle Differences Between Agile Paradigms


Testing based on implementation knowledge can also lead brittle tests that break, due to the fact they are dependent on the structure of your code and not just the behavior. For example, if the PersonService.findPersonByName ever evolved to call another service, like maybe a logger, the test would have to be updated to create a new mock. Thus, creating a test that finds a person now must be updated because I added a cross-cutting concern such as logging? This seems to break the "test only one thing" rule of thumb. This could trickle to hundreds of tests! This is an example of tests that are dependent on the internal object structure of a system and not the behavior.

Due to the motive of BDD, its proponents focused on correcting the false impressions of the test-Driven development and introduced the term "behavior-Driven." This led to introducing naming conventions on test classes and test methods with the intention of leading the developer to think more in terms of the behavior of the system. BDD also relaxes the constraints on only creating pure unit tests, where a class or module is tested in isolation. BDD developers often create tests which test a few modules together or one that hits the database, or even a traditional pure unit test which is isolated. The behavior specification is what is important and is the focus, not the implementation.

An example test class exemplifying BDD conventions is below. Notice the test class name has "behavior" and the test method name has "should":

WindowControl should close windows
public class WindowControlBehavior {
public void shouldCloseWindows() {
WindowControl control = new WindowControl("My frame");
AFrame frame = new Aframe();

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.