Per my last post about the splendor of GAE, below is one example of a tool I built for us at Socialize to keep an eye on code coverage and lets the group know if a build is broken (if our tests have failed.) This script is built to run on Google AppEngine, checks against a TeamCity Server install, and expects that each project in team city has code coverage outputted to its artifacts folder.
What is C.I. Server and why is it important?
C.I. stand for Continuous Integration, and is a system used to constantly/”continuously” checks to see if a code base is “working” or not. Team City (by JetBrains) is a product made for that process. Usually it is used to run tests against a code base to make sure it is working as expected, as a part of the QA life cycle. These tests are made up of “unit tests” that are created by the developers whom write code to test the code they are writing. It can be a bit odd for those that have not ever done so, but it is quite important when trying to deliver stable code. In short, and in its simplest form, this whole system makes sure new code/changes doesn’t break old code already in place. You can read more about these processes and purposes here: Unit Testing & Integration Testing.
What is code coverage, and why is it important?
Code coverage examines how much of your code is being tested. For instance, you may have a C.I. system in place, and a unit test frame work running within it, but if the tests only test/”cover” 1% of all of the code you aren’t really delivering a level of confidence you should be. In this tool we track the coverage percentage over time. Seeing it as a graph helps recognize dips in coverage easily.
Sean Shadmand 