Chapter 5

Chapter 5 centers around the idea of Domain Class Development. Throughout developing code, the following three topics are present:

• Coding
• Unit testing
• System testing

Reusing Legacy Code

One of the first steps to coding Domain Classes is looking internally within the codebase for any code that can be repurposed. When looking internally, well commented and documented code and meaningful variable names will make the process run as smooth as possible. By commenting and documenting the processes that it took to deveop the original code, reuse can be determined quickly and save time when considering whether or not to create a new class from scratch. If the legacy code meets the above criteria, it can be moved into the next three phases:

• Downloading the legacy code
• Identify and retain the necessary code for reuse
• Declare/add new instance variables to the legacy code

One the code has been refactored with the added functionality, the only additional steps are to ensure the constructor works or add the necessary functionality for the new class and add the necessary getter functions for the new private variables.

Testing

Now that the code has been refactored and improved with the necessary private variables, testing should begin to ensure that the code is functional before full deployment into the production environment. Depending on the programming language that the project has been implemneted with, the following unit testing frameworks can be used:

• JUnit (Java)
• PHPUnit (PHP)
• Pytest (Python)
• testing (GO)
• cmoka (C)

Once a testing framework has been selected, the test cases should have the following traits:

• Tests should be grouped into test suites
• Unit Tests should test all of the class’s functions, including the constructor
• Test calls should be asserted to either true for a pass or false for a failure/unexpected test oracle
• Tests should aim for 100% code coverage and 100% use case coverage with every line of code being tested in the class

Once Unit Testing has concluded, Integration Testing can begin with the following concepts being implemented:

• Classes and modules should be tested separately
• Each of the tested modules of the classes, modules, and unit tests should be pushed and merged to the main codebase
• The merged code should be pulled into the developer’s version of the codebase

Debugging and Refactoring

Debugging

Debugging code is neccessary, but GitHub makes the process easier and centralized with the issue tracker within a repository.

Refactoring

Refactoring code is always a plus, since it requires looking over the code again and allows for functions to be reviewed and classified as the following:

• Necessary: the function is used and is necessary for the class
• Redundant: the function’s purpose is fulfilled by another function or functions within the class or project
• Useless: the function is not used within the project and is taking up extra lines of code

Also included in refactoring are the following:

• Renaming
• Extracting function(s)
• Reorganizing
• Removing useless code
• Removing layering violations
• Merging functions/modules
• Separating Model, View, and Controller code

Client Review and Issue Tracking

For client review, the code should be refined and thoroughly tested and deployed in a sandbox for the client or users to test within their workflow. In conjunction, issue tracking should be done to ensure that bugs can be addressed for the project for the specific client’s use case of the software. The process in reporting an issue can be done by the following:

• By the developer/client during review
• The issue is posted as open with the followin
  • Title
  • Description
  • Example/replication of the issue
• Open issues are reviewed by the project lead and traiges the issue’s priority and whether it overlaps with another issue within the project
• The issue is assigned to developers by the lead
• Once corrected and reviewed, the patch can be approved and once it is approved, the issue is marked as closed