Code Coverage

In our Google Summer of Code project a part of our work is to bring knitting to the digital age. We is Kirstin Heidler and Nicco Kunzmann. Our knittingpattern library aims at being the exchange and conversion format between different types of knit work representations: hand knitting instructions, machine commands for different machines and SVG schemata.               The image above was generated by this Python code: import knittingpattern, webbrowser example = knittingpattern.load_from().example("Cafe.json") webbrowser.open(example.to_svg(25).temporary_path(".svg")) So far about the context. Now about the Quality tools we use: Continuous integration We use Travis CI [FOSSASIA] to upload packages of a specific git tag  automatically. The Travis build runs under Python 3.3 to 3.5. It first builds the package and then installs it with its dependencies. To upload tags automatically, one can configure Travis, preferably with the command line interface, to save username and password for the Python Package Index (Pypi).[TravisDocs] Our process of releasing a new version is the following: Increase the version in the knitting pattern library and create a new pull request for it. Merge the pull request after the tests passed. Pull and create a new release with a git tag using setup.py tag_and_deploy Travis then builds the new tag and uploads it to Pypi. With this we have a basic quality assurance. Pull-requests need to run all tests before they can be merge. Travis can be configured to automatically reject a request with errors. Documentation Driven Development As mentioned in a blog post, documentation-driven development was something worth to check out. In our case that means writing the documentation first, then the tests and then the code. Writing the documentation first means thinking in the space of the mental model you have for the code. It defines the interfaces you would be happy to use. A lot of edge cases can be thought of at this point. When writing the tests, they are often split up and do not represent the flow of thought any more that you had when thinking about your wishes. Tests can be seen as the glue between the code and the documentation. As it is with writing code to pass the tests, in the conversation between the tests and the documentation I find out some things I have forgotten. When writing the code in a test-driven way, another conversation starts. I call implementing the tests conversation because the tests talk to the code that it should be different and the code tells the tests their inconsistencies like misspellings and bloated interfaces. With writing documentation first, we have the chance to have two conversations about our code, in spoken language and in code. I like it when the code hears my wishes, so I prefer to talk a bit more. Testing the Documentation Our documentation is hosted on Read the Docs. It should have these properties: Every module is documented. Everything that is public is documented. The documentation is syntactically correct. These are qualities that can be tested, so they…