CODEWITHSUNDEEP
testingtddautomated-tests
Baz
Baz

Reputation: 13125

Applying TDD to Function Testing

We have been developing a product for 2 months now and it has a high rate of unit test coverage. Most of us are also writing our tests first and code after. This means that we can trust our tests since we use the red first, green later approach.

To date, we have demoed our functionality to the customer by hand. However, as we begin to cover more and more requirements it has become necessary for us to cover these requirements using function tests.

At the moment we have no function tests.

We have a team member who handles requirements and I believe he would be a good person to write the function tests. My concern though is that the development of functionality and the writing of function tests will be out of sync. That is, that tests are not necessarily written before the functionality is fully implemented.

Should we have a rule henceforth that function tests are written before the functionality? Red first, green later in other words. Or are there other approaches.

Upvotes: 0

Views: 108

Answers (2)

John Deters
John Deters

Reputation: 4391

The methodology you are describing that you want to get to is called Behavior Driven Development (BDD). Essentially, it's similar to Test Driven Development for functional testing. A requirement or behavior (or use case or scenario, however you specify requirements in your own shop is up to you) is described in the form of a functional test, complete with entry and exit conditions, and then TDD is repeatedly employed to achieve that behavior in your system.

One simplistic (and light weight) open source framework that supports BDD is called FitNesse. It's a wiki-style editor for capturing requirements. In each requirement you include a table of example requests and results, and Fitnesse then automatically calls the services and tests them for you. It's not the greatest tool out there, and I don't think it scales well, but it's something you can get started with quickly. Another tool (better than FitNesse, or so I've heard) is soapUI It is much more complete, and can do things like stand in for missing services, do load testing, organize tests, and more.

One difference between TDD and BDD is that in BDD your functional tests may or may not be fully automated, depending on the nature of the behaviors. The more automated the better, but sometimes it's easier to have a human to run through a script, or eyeball some results. The test environment you'll need for BDD will also likely be more complex, incorporating actual databases and services. While that means you can do full testing of the behavior in a realistic way, it also means you have to have a test environment full of the resources your application will depend upon. That's not a bad thing, it's just where your testing gets real.

Upvotes: 2

Jakob
Jakob

Reputation: 749

You should not lock yourself into patterns if they do not work for you (red first, green later for example). In your case, I see no problem with having the functionallity in place before you do the functionallity tests since you already have good unit test coverage in place.

But that is only me, Im sure hardcore TDD:ers will disagree.

Upvotes: 2

Related Questions