Many developers claim that to achieve high quality software, developers must create automated tests that ensure that all possible execution routes have been covered. This is also known as full path coverage. I will argue that different types of software require different testing approaches and that full path coverage is impractical in almost every case. Too many tests simply create clutter. Read more…
I have recently read a blog post claiming that functional tests are not “true” tests. The author also claims that unit testing shows you where the problem is occurring, while functional testing simply identifies that a problem exists. This argument is deceptive and the conclusion dangerous. Different kinds of tests are not mutually exclusive. One is not superior to the other. They have different goals and can happily coexist. Let me explain the kinds of tests so that you could make enlightened decisions.
Do you want to write unit tests but don’t know where to begin? Don’t panic and follow these steps to ease into the testing business. Practice testing often to achieve best results.
Tip: try to test the smallest unit possible, usually a function, rather than a combination of functions. Testing combinations is called integration testing, which I will cover in subsequent posts.
Here are a few easy to spot opportunities for writing unit tests.
Read more…
I have a test suite with PHPUnit and Selenium. I recently upgraded to Selenium 2 (Selenium WebDriver) and updated my PHP code. I specified explicitly in my code that Firefox should be used but the tests consistently opened Chrome instead.
The error did not come from the fact that I incorrectly updated my code. You see, with Selenium 1 test cases, browsers were defined like this: *firefox. With Selenium 2, you have to drop the asterisk like this: firefox. Otherwise, your system’s default browser will be used.
That’s it. Happy testing!
It’s been bothering me for quite some time not being able to explain the people out there why they need to write unit tests. The most common responses that I got were “this is a waste of time” and “my application has no bugs”. Unfortunately, this overconfidence and cutting corners is hurting the developers (and the industry).
I compiled this short list of why I write unit tests:
-
Don’t let your customers discover embarassing bugs. Write tests to cover a multitude of scenarios and catch these bugs before they get into production.
-
Test complex scenarios quickly, without having to manually reproduce them in the application.
- By testing often, you don’t break the application as you go. You can’t always know the indirect implications of what you’re writing, especially if you didn’t write the original application.
- By testing early, you don’t write unnecessary code but only the strict necessary. This makes the codebase smaller and more maintainable. It also saves on development time.
- You do not have to debug the same code twice. Once you have a test to account for a possible bug, you’ll pick up any wrong turns quickly.
- You ensure readability. A unit test makes the purpose of your code easier to understand.
- You ensure maintainability. Unit-testing forces you to better encapsulate functionality, thus making it easier to maintain and add new features.
-
Refactor without worries. Run the tests to make sure everything still functions as intended.
-
Save time on testing. You can test the entire application at the speed of your CPU.
-
Feel safer. How many times were you afraid to add a new feature or change something in your application’s core? No more!
- Bonus: know exactly what is broken. Instead of hunting for an obscure bug, let the tests tell you what’s wrong and why. Example: the application will tell you when you add an item to a cart but the cart still appears empty. It will also tell you what item you tried to add for the cart to break.
You may have different reasons, so share them in your comments.
Recent comments