-[Questions about Test-Driven Development](#questions-about-test-driven-development)
## Introduction
Test-driven development (aka TDD) is the practice of writing code which tests a number of possible scenarios (ideally all) around the various features of your application, while developing your application. Some people take this approach to the extreme and write a large number of tests before even starting to write the application itself.
OpenLP already has a well-established codebase, so we will not be following that extreme, but below are some '''why''', '''what''', '''how''', '''when''' and '''who''' questions, with answers, which should help folks to understand how we are implementing TDD.
## Questions about Test-Driven Development
### Why do we write tests?
The goal of writing tests is to check so much functionality in your application that ''when you add a new feature or fix a bug, the tests will pick up any regressions or new bugs before the code is actually released''.
Having tests allows faster development and at the same time keeping the code stable.
### What do we test?
EVERYTHING!
On a more serious note, the goal is to test small segments of code, typically functions and methods.
You should also be writing a test for each logical path in the code. In other words, each <code>if</code> and <code>else</code> should be tested.
### How do we write tests?
This question is answered nicely in the [Unit Tests](Development/Unit_Tests"wikilink") section. Additionally, each code path should have its own test. If you're writing more than one scenario in a test, you need to break your test up into separate tests for each scenario.
### When do we write tests?
As mentioned before, some developers like to write a large set of tests before even embarking on writing application code. We are not quite that extreme, but here are some good practices to implement.
### Before you code
You should write a test, or tests, before you start fixing that bug or implementing that feature.
### Stub things out
If you're writing a new feature, it is often useful to stub out a few new methods that you'll be using, and then write tests around what those methods should be doing.
### Reproduce the bug
If you're fixing a bug, write a test that specifically exploits that bug. This way, when you fix the bug you can double-check that you've fixed it by running that test and seeing that the test passes.
### Who writes tests?
We all do! Any merge proposals for OpenLP 2.1 and higher will not be accepted without a test. Even if you're refactoring the code, add a new little test for some of the code you've just refactored. This way we can get as much of OpenLP tested as possible without having to put off development for 6 months while we write tests.
