Testing is an un-skippable part of any development process (even if it does get skipped in practice). There are different methodologies you can use for your testing. The two big methodologies being used right now are test driven development (TDD) and behavior driven development (BDD).
They both have their own ways of handling testing and they both work best when used together. That's why it is a good idea to know about both so that you can choose what works for your projects.
TDD
Test-driven development is a process focused on writing tests. You write tests before you write any code. Then you check to see that the test fails, which you would expect since there is no code implemented yet. Next you'll write the minimum amount of code needed to pass the test. Once your code is passing the test, you can work on refactoring it to make it more efficient.
You go through this process for every piece of code you write. That means you'll end up with a lot fewer bugs, it'll be easier to add new features, and you have a final check of any merged code before you deploy to a production server. That is the heart of TDD.
It's hard for many developers to use TDD in the beginning because it feels strange writing your tests before you have any code to test. This is a skill that you really have to work at building but once you get it, the pay off is incredible. The reliability of your code skyrockets, you don't have to depend on outside tools for your testing, and your overall programming skills start to improve.
BDD
Behavior-driven development is completely different from test driven development. BDD is actually a set of best practices for writing really good tests. One of the most important issues BDD addresses is how you do the implementation for tests.
With BDD, you focus on writing tests to check scenarios or behaviors instead of checking the implementation of your code. Most of the time you'll see tests in BDD written like: "it should do something". An example of this is: "should create user id after calling save". One advantage of writing tests this way is that you won't have to update the test implementation every time you update the code implementation.
That's one of the biggest complaints I've heard from developers about testing. BDD fixes that. Since you're testing behavior instead of implementation, the code implementation doesn't impact the test implementation.
How they complement each other
Test-driven development and behavior-driven development complement each other. TDD makes sure that you write tests in the first place and BDD tells you how you should be writing those tests. Then you have a well-defined testing process that can be applied to any project, regardless of the programming language(s).
Behavior-driven development forces you to think about every step a user will go through. This really helps you learn how to figure out what a client or a manager really wants you to do because you start thinking about business cases.
Test-driven development forces you to write tests for each of those behaviors. When you know the exact behavior a user is expecting, it makes it easier to write the code for it. It makes you write more efficient code because you are only writing enough to pass the test and that test maps directly to a user process.
By combining both methodologies, you get the most benefit from your testing efforts. Then you can start getting into automated tests which makes things even easier when all of the tests have been written in a useful way.
Are there any other testing methodologies you're familiar with? These are just the ones I've worked with so I'm curious to hear about any others out there. 🙂
Hey! You should follow me on Twitter because reasons: https://twitter.com/FlippedCoding
Top comments (5)
Hi, thank you for your post. The way I've always understood it is that, BDD is TDD done right. TDD tells us that we have to test our code before we develop. BDD tells us which code matters that warrants testing.
Great post. I am a big TDD proponent and have said the exact thing in the past to others! Also Dan North, the person who created BDD, said that was his intention. You will even see examples of people using the given/when/then format in their tests.
Hi, this is the clearest way I've come across of describing the right way of doing testing for client facing systems (IMHO :)). Thanks for this, and I'll definitely be pointing my team at it.
Very helpful article. It enhanced my thought about BDD. BDD uses the test-first approach which is the core idea of TDD but the tests in BDD are business functionality oriented instead of code oriented.
"One advantage of writing tests this way is that you won't have to update the test implementation every time you update the code implementation." - I dont get that. Why we need update the test when the code implementation changes?
For example: Writing function which calculates Fibonacci.
In TDD: assert.equal(1, factorial(0));
In BDD: factorial(0).should.equal(1);
When we change the implementation, we dont need to update this test.
I only see the difference in syntax. Can you figure out with this example?