intro
We can test our code in quite a few ways. We typically use debugging tools such as byebug as we want to make sure things are behaving as they should (or when they don't...). A well placed puts
may be all you need to see what is happening in a specific spot in your code. We could use the console to test our methods. Giving them data to work with and seeing what we get back in return.
But for proper testing, we would use test frameworks (or suites ).
A test framework would allow us to write external files that will run our code and check if the results are as expected.
Ruby on Rails comes with its own test framework, but we will be discussing how to use RSpec in this blog.
Writing your own tests
Instead of writing tests to check if the code that we have written works as expected, in TDD the practice is to write tests before we write our implemented code.
This practice of development, leads us to stop & think about what we are trying to achieve, and how we are going to build it.
If we jump straight into implementation, we could lose sight of what our exact expectations from the code should be.
This leads to wasting a lot of time writing unnecessary code.
For starters, we may:
- Write tests that match what we are trying to accomplish.
- Run our test (it will fail, as we have not yet written any code).
- Think about how to write code that will lead us to pass the test.
- Write the code, and test it.
- Repeat step 4 until all tests pass
- Refactor code and make sure it still passes the tests.
Sticking to this process will have you stay on-point with your goals, writing precise meaningful code and checking that it all works, all-in-one.
BDD - behavior-driven development, is a step forward from TDD.
I will not touch much on The differences here. But suffice to say that BDD is tested from an end-user view point, and requires a team to prepare (including managers and test engineers), and that BDD is testing a feature, not just small slices of code.
RSpec
I will not be getting into how to setup RSpec in your project, although the process is simple enough.
In RSpec we write tests that are also the specs (specifications) for our applications behavior.
We use the describe
keyword to define our test block,
then we describe what behavior is expected.
The test accepts either a class name (from an existing class) or a string.
Let's assume we are writing a test for a calculator app.
We have a class method called ".exponent_calculator" designed to calculate the result of an exponent of a number (x**y = result).
describe Calculator do
describe ".exponent_calculator" do
context "given two numbers" do
it "returns a result of the first number raised to the power of the second number" do
expect(Calculator.exponent_calculator(2,10)).to eq(1024)
end
end
end
end
We are describing in plain English what is expected of the method, and in what context (context is optional).
This makes our test very easy to understand and maintain.
Running rspec
will then then check if sending in the numbers 2 and 10 into the method will return 1024. The test will pass or fail depending on results.
For better testing you would want to test for edge cases as well.
Make sure to consider all possible input (imagine testing a quadratic equation calculator. Or better yet go build and test one yourself - it's quite fun.)
When you write your implemented code, check what happens when you purposely fail the test - check that it really only passes when you need it to.
Conclusion
There is so much more to cover about testing - testing can even become your career path. This was just a small taste of what testing is about. Like it or not, at the end of the day testing is a big part of developing. TDD and BDD are going to be part of your life in some way.
References
rspec GitHub page
A nice beginner's tutorial I found
BDD vs TDD
Top comments (0)