As you can see, testing can be quite involved, and overwhelming to a developer, but it is currently, with the exception of formal method modeling, the only way to be sure your code is doing what you say it is doing. Empirical analysis on instrumented code can show you each and every line in your code that is “covered” by a test. This coverage information is good and bad. It is good because you have a number which marches forward or backward that you can use as a gauge of how much quality your code has within. It is bad because, just like any other gauge, developers can tweak the coverage numbers without actually increasing quality. By merely running code within the testing framework, the coverage number will increase but if your tests do not have valid assertions and are looking for the right things, the test is bunk. A pragmatic and honest approach to testing is a contract between the company and the developer. If a company demands 100% of the lines of code covered by tests, then the developer will cut corners on the tests to make that number. If the company demands more functionality and less testing, then the quality will obviously suffer. There is a fine balancing act that needs to be achieved based on risk.

Within the next chapter, we will be focusing on content delivery with templates and static content. Typically, this is how the world "sees" your web application, through delivery of content. It will be shown how Echo provides a great mechanism for dynamic and static content rendering.