By now, my post on unit tests influenced you so much that now you have 100% unit test coverage. But yet, some functional bugs still creep in and you still get the dreaded “It’s a bug because you didn’t build what I wanted” bug.
So let’s take a look at acceptance tests and how they can you help you improve your external quality and your compliance with product requirements.
As powerful and useful as Git is, it’s not all fun and games. It can be down right intimidating and hard to use.
But with some customization on your part, and some changes to your team’s Git workflow, Git can become a far more tammer beast to conquer.
As a recent convert to Test Driven Development (or TDD as his friends call him), I was surprised to hear that there were in fact 2 kinds of developer driven testing. The standard one that everyone knows of is unit testing: writing little testXXX methods that test a single publicly exposed method. But the lesser known – but just as important – are acceptance tests: tests which verify that a group of classes working together properly fulfill some functionality.
So this first post will take a closer look at the first type of testing, unit tests, and will go into the value it provides to you as a developer.