It's okay to never test code that never changes. For everything else, you need tests.
WHAT'S IN THIS CHAPTER?
Black box and white box test defined
Testing with equivalence classes
Testing entire systems
Testing signup and login functionality
Advantages of acceptance tests
Testing part of an application with unit tests
Testing an example MVC controller
In classical, non-iterative software development, programming and integration or system testing are two distinct project phases, and they often are executed by different teams. It makes lots of sense not to have developers test their own work. An independent tester approaches the product with a completely different view, because he does not know any implementation details. Thus, he is forced to focus on testing the API, and he uses the application in a different way than the original developer, who still thinks about the code intuitively and might tend to test the functionality that is already known to work. Independent testers usually develop enough destructive creativity to really put the developer's work to the test and try out really nonsensical input, interrupted actions, or even manipulated URLs. First-time users of an application, by the way, are also great testers.
Tests that are executed without knowledge about implementation details are called black box tests. Tests that are developed based on the source code of an application are called white box tests.