Chapter 5 of Client-Centered Software Development revolves around Domain Class Development. This involes finding and resuing code from earlier open source projects and coding some classes from scratch. This chapter also covers unit testing principles.
Reusing External Legacy Code
Some domain classes are so common that they reoccur in many open source projects. Person class is an example. New CO-FOSS projects should first look outside its own omain for similarly well devloped solutions that fit its needs.
Reusing Internal Legacy Code
Many Co-FOSS projecs involve upgrading existing open source products to meet additional requirements and fix serious shortcomings in the product. This requires more effort than a standard usability issue.
Coding Domain Classes from Scratch
Most domain classes aren’t as straightforeward as sugessted. In realit ymost domain classes are unique to that application. More likely these domain classes will be coming from within the same organization.
Adding Functionality with Constructors and Getters
Not all functions in a new class can be predicted but it is safe to include a constructor for anew object in a class and a series of so called getter functions for each instance variable.
Software Testing
Do not wait until the end of development to test. This must be integrated into the development process and done throughout the coding process. Test driven development places requirements gathering ahead of development. This code will be refined as we go on.
A good integrated development environment supports continuous testing alongisde coding. A lot of testing frameworks can be integrated into the IDE your using such as Eclipse. The architecture of your code base should support continuous testing as well, like a directory of test cases that coexist among the code directories. While this does add storage overhead, it is good practice. It is worth noting that even the most systematic testing does not insure that the code is free of bugs.
Designing Test Cases
To continuously and systematically test software, we need a collection of tests called a test suite. A test suite should have one unit test for every module or class in the code and one unit test for every use case. A unit test contains a group of calls that exercise all the module’s functions. This call is called an assertion that delivers a boolean response. A test suite should aim for 100% code coverage and 100% use case coverage.
There are unit testing frameworks available to automate running these tests. Integration testing is performed after all the individual units have been tested independently.
Debugging
Debugging is important to CO-FOSS and there are tools such as GitHub that help us track issues. This is also aided by the fact that the users of this software are also the developers. Sometimes when a new team takes over a project or a new feature is looked at being developed, developers will identify “bad smells”. This refers to code that doesn’t allign with the codebase, styling, or is not clear or consise. Sometimes the writer of code may not be around so it is up to the existing developers to flush out these problems by improving on this code. Software metrics can also be used to aid in code performance. Refactoring is the process of improving code without changing its behavior.