Testing software is one of the most important aspects of software development. It ensures that the code you are writing is doing what it is supposed to do. Now and in the future.
Having a comprehensive set of tests for your code gives you confidence that it does what it is supposed to do. It also helps bestow that confidence on others. Other people who are using or maintaining your code.
Running tests some time after you created your code, for instance after some components you rely on have been updated, will tell you if your code still works or you need to make changes.
There are a lot of different kinds of test. I’ve list a couple here, in order in which they are used in a real programming project:
I’m not going to explain in-depth what Waterfall and Agile means. You can look it up on Wikipedia.
Basically, use the Waterfall method if: you are designing a spaceship to fly to Mars, some medical device or anything that must work according to a specification with a minimal chance of errors. This means analyzing, describing, documenting every aspect of the software before it is built.
If you are designing the next instant messaging platform, business app or anything where the exact specifications are not known in advance, but will change along the way, use an Agile development method.
The following topics are specific to Agile.
Test Driven Development: Write your tests first, then write your code.
When you develop a new piece of code or add a new function to existing code, first define a set of tests that the final working code should pass. Next run the tests. Most likely all tests will fail. Now start implementing and refactoring your code until all tests pass.
The main advantage of this way of working is that you focus first on what your code should do, instead of on how it should work. In practice the effect is that you write less code.
Behavior Driven Development: an extension to TDD to include the clients functional requirements.
Before implementing any new code you need to know what the desired behavior of that code should be. In other words what does the client, paying your bills, want. This involves the client and the developer speaking the same language. A language also known as plain English. BDD uses a fixed layout to write down user stories.
Here is an example from Cucumber:
Feature: Multiple site support
As a Mephisto site owner
I want to host blogs for different people
In order to make gigantic piles of moneyBackground:
Given a global administrator named “Greg”
And a blog named “Greg’s anti-tax rants”
And a customer named “Dr. Bill”
And a blog named “Expensive Therapy” owned by “Dr. Bill”Scenario: Dr. Bill posts to his own blog
Given I am logged in as Dr. Bill
When I try to post to “Expensive Therapy”
Then I should see “Your article was published.”
Each feature usually has many scenario’s.
Ruby has one of the most advanced set of testing tools available anywhere.
For supporting TDD style testing both rspec and minitest are very popular. BDD style testing is often done with cucumber. Cucumber lets you translate functional requirements written in plain English into executable (!) tests for your Ruby code.
Testing is not supposed to involve additional work. This would soon lead to less testing. The answer is automating tests. When the test automation tool notices you have changed a (Ruby) file, part or all of the tests are executed again. And you will be notified of newly failing or passing tests.
Test automation can for instance be done with autotest or guard. Guard can automate lots of other tasks for you as well.