Chapter 5

This week’s reading (Chapter 5 of Client-Centered Software Development) covers domain classes and unit/system testing. According to the text, “domain classes are the central element in a CO-FOSS product that is customized to fit the needs of a single client.” Domain classes are what customize the general open-source product to fit the needs and terminology of the client’s familiar working environment. The example given by the chapter is a person class. Most projects include such a class; it needs to be configured from the base class to include information about each instance - each person - appropriate for the specific project. However, in many cases, domain classes are unique to the project and must be built from scratch.

This chapter also integrates its discussion of domain classes with a discussion of software testing. Of course, in CSCI 362 with Dr. Bowring, our entire semester focused on software testing. I kept what I learned in mind when reading this portion of the chapter. It first covers unit testing, then system testing.

I found some of the author’s ideas about unit testing particularly interesting. One point of emphasis is that testing should be implemented throughout the process of software development, absolutely not just at the very end of it. Traditionally, most companies tested at some point when all of the code had been completed. The more contemporary approach is called test-driven development (TDD). I remember learning about TDD last semester. It’s an intuitive idea that integrates the two processes, ensuring healthy code at each step.

Once the software has “gone live” with the client, the debugging process - distinct from the testing process - begins. Testing finds bugs and errors via the unit testing system while debugging finds the root cause of said bugs ad errors. In addition to testing, the author paints the client as one of the most helpful tools in identifying software errors. I can attest to this from my experience at my current job. I work on the technical operations team. There have been several cases where an internal user or a customer reports a bug that they found while using the live software. While this is not ideal, it is inevitable because the client uses the product much more often than anyone else.

Finally, the author identifies some important steps to take after bugs are identified, whether via the testing framework or the customer. Before new features or fixes are implemented, code should be routinely checked for “bad smells”. You do not want to be building on top of bad code because this will require you to either follow bad practices in your new code or sacrifice consistency. Additionally, an easy-to-overlook step is adding new test cases that correspond to the bug fix. As the code expands, the test suite must expand and adapt as well if it is to remain useful. This is something I came across in my work for the semester project. In that case, the test suite had to adapt rather than expand. I adjusted the search functionality. Consequently, the expected results of search-related tests failed, causing my pull request to fail some checks. I had to adjust those expected values for a couple of test cases to accommodate my code. It’s fun to be able to make connections between theory and practice in this course!

• 2021 11
• 2020 22