Using command-line options, you can filter out counted lines. This recipe assumes you have already created the network management application as described in the Building a network management application section.
With these steps, we will see how to filter out certain modules from being counted in our coverage report.
- Create a test suite that exercises all the code functionality.
from network import * import unittest from springpython.database.factory import * from springpython.database.core import * class EventCorrelationTest(unittest.TestCase): def setUp(self): db_name = "recipe56.db" factory = Sqlite3ConnectionFactory(db=db_name) self.correlator = EventCorrelator(factory) dt = DatabaseTemplate(factory) sql = open("network.sql").read().split(";") for statement in sql: dt.execute(statement + ";") def test_process_events(self): evt1 = Event("pyhost1", "serverRestart", 5) evt2 = Event("pyhost2", "lineStatus", 5) evt3 = Event("pyhost2", "lineStatus", 1) evt4 = Event("pyhost1", "serverRestart", 1) for event in [evt1, evt2, evt3, evt4]: stored_event, is_active, updated_services, updated_equipment = self.correlator.process(event) print "Stored event: %s" % stored_event if is_active: print "This event was an active event." print "Updated services: %s" % updated_services print "Updated equipment: %s" % updated_equipment print "---------------------------------" if __name__ == "__main__": unittest.main() - Clear out any previous coverage data by running
coverage-e. - Run it using
coverage-xrecipe56.py. - Generate a console report using
coverage-r. In the following screenshot, observe how Spring Python is included in the report and reduces the total metric to 73 percent.
- Clean out coverage data by running
coverage-e. - Run the test again using
coveragerun–sourcenetwork.py,recipe56.pyrecipe56.py. - Generate another console report using
coverage-r. Notice in the next screenshot, how Spring Python is no longer listed, bringing our total coverage back up to 100 percent.
- Clean out coverage data by running
coverage-e. - Run the test using
coverage-xrecipe56.py. - Generate a console report using
coverage-rrecipe56.pynetwork.py.
Coverage provides the ability to decide what files will be analyzed and what files will be reported. The steps in the previous section gather metrics several times, either running it with a restricted set of source files (in order to filter out Spring Python), or by requesting an explicit set of modules in the report.
One question which arises from all this is what's the best choice? For our test scenario, the two choices were equivalent. With approximately the same amount of typing, we filtered out Spring Python and got a report showing network.py and recipe56.py with 100 percent coverage either way. However, a real project with a lot of modules and possibly different teams working in different areas would probably do better by gathering all the metric data available and filtering at the report level.
This way, different reports on subsystems can be run as needed without having to keep recapturing metric data, and an overall report can still be run for whole system coverage, all from the same gathered data.
The options used in the previous section were inclusive. We picked what was to be included. The coverage tool also comes with an –omit option. The challenge is that it's a file-based option, not module based. It doesn't work to –omit springpython. Instead, every file must be specified, and in this case, that would have required four complete files to exclude it all.
To further complicate this, the full path of the Spring Python files needs to be included. This results in a very lengthy command, not providing much benefit over the ways we demonstrated.
In other situations, if the file to be excluded is local to where coverage is being run, then it might be more practical.
The coverage tool has other options not covered in this chapter, such as measuring branch coverage instead of statement coverage, excluding lines, and the ability to run in parallel to manage collecting metrics from multiple processes.
As mentioned previously, the coverage tool has the ability to filter out individual lines. In my opinion, this sounds very much like trying to get the coverage report to meet some mandated percentage. The coverage tool is best used to work towards writing more comprehensive tests, fixing bugs, and improving development, and not towards building a better report.