Pursue code Quality

Obviously, the test itself is a good thing. Early testing-for example, when writing code-is more beneficial, especially in improving code quality. You'll benefit a lot from writing tests early in your development. You can check the behavior of your code and debug it in advance, which is a huge motivator.

Even with this importance, we have not reached a critical point: making testing before writing code a standard practice. Just as TDD is the next evolutionary phase of extreme programming (Extreme programming), which introduces the unit test framework, the new leap will come on the basis of TDD. This month, I invite you and me to implement the evolution from TDD to more intuitive behavior-driven testing (BDD).

Behavioral-driven development

While test-first programming works for some people, it doesn't apply to everyone. While some application developers are fanatical about TDD, others are adamant about resisting it. Even though there are already many test frameworks, such as TestNG, Selenium, and FEST, the justification for not testing the code is still sufficient.

The two common reasons for not using TDD are "there is not enough time to test" and "The code is too complex to test." Another hurdle for testing priority programming is testing the priority concept itself. Many people think of testing as a reactive activity, only a little more specific than abstract. Experience tells us that we can't test things that don't exist. For some developers, testing first is a paradox in this conceptual framework.

But what happens if you don't consider writing tests and how to test them, but thinking about behavior? The behavior here refers to how an application should run-actually refers to its specification.

As a matter of fact, you have thought of this approach. We all thought about it. Please see the dialogue below.

Frank: What is a stack?

Linda: It's a data structure that collects objects in an advanced, backward (or LIFO) way. It usually has an API, which includes methods such as push () and pop (). Sometimes there are peek () methods.

what function does Frank:push () have?

Linda:push () accepts an input object, such as Foo, and puts it into an internal container (such as an array). Push () usually does not return results.

Frank: What happens if I push () two objects, like Foo First, then bar?

Linda: The second object bar should be at the top of the stack (at least two objects), so if you call Pop (), then you should return bar instead of Foo. If you call Pop () again, you should return foo and the stack is empty (assuming there are no objects in the stack before adding the two objects).

Frank: That is, Pop removes the item that was recently put on the stack?

Linda: Yes, pop () should remove the top item (assuming there are items in the stack that can be removed). Peek () is similar to this, except that the objects in the stack are not removed. Peek () should keep items on top of the stack.

Frank: What happens when you call POPs () if you haven't pushed any items before?

Linda:pop () should throw an exception indicating that no item has been pushed in the stack.

Frank: What happens if push () null?

Linda: The stack should throw an exception because NULL is not a valid value to push ().

Did you notice anything special in this conversation (except that Frank is not a computer science major)? The word "test" is not used here from beginning to end. However, the word "should" is very naturally flashing everywhere.

What's the nature of it?

What kind of framework should I use?

Because of the annotations (annotation), you can use JUnit and TestNG to practice BDD. I find it more interesting to use a BDD framework such as JBehave, because it provides features that define behavior classes, such as an exception framework that facilitates more literary-style programming.

BDD is not a new thing, much less a revolutionary breakthrough. It's just a branch of TDD where the word "test" is replaced with "should." In addition to semantics, many people also find that this concept should be a more natural development driver than the concept of testing. Considering behavior (should) naturally prompts you to write the canonical class first, which can be a very effective implementation driver.

Based on Frank and Linda's dialogue, let's see how BDD drives development in ways that TDD wants to promote.