Exploring the Subtle Differences Between Agile Paradigms

  1. calls.

At this point I have entered the mindset of "testing" and not just the behavior of my PersonService class. If I was only worried about the behavior and abstracted myself away from implementation, the first test I create would only consider that the invocation of PersonService.findPersonByName returns a Person object named "bob", regardless of the implementation. What if we extended this example to a method that didn't return anything, i.e. it returned void? Thus, we may write a test that only verifies that a mock is called. What does this really accomplish other then satisfying code coverage and validating that you called what you intended to call. These are legitimate concerns but not "behavior-Driven" concerns. They are more unit testing and general "testing" concerns. In my experience, I have seen tests in projects that verify mocks and all the tests pass, but since no behavior was validated through tests the system behavior was not met. Thus we had a situation where unit tests passed, but the code had a bug. This is classic verification without validation. Essentially it is doing the right thing, but not doing the thing right.

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();

Feature-Driven Development
Jeff De Luca and Peter Coad are the founders of Feature-Driven Development. FDD is a methodology created in the agile spirit and meant to address the problems of the traditional waterfall process. Overall, it is a management methodology for software, but it also contains a few integrated ideas in the realms of requirements analysis and domain modeling. The sum of its ideas creates a methodology that is structured and easy to follow. It is a simple, iterative, and well defined process.

FDD is defined by these simple steps

  1. Develop an overall model
  2. Build a features list
  3. Plan by feature
  4. Design by feature
  5. Build by feature

The first 3 steps are considered the "startup phase" and the last 2 steps are done iteratively

About the author

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!