Journal 3:

This journal covers the Process, Construction, and Testing Learning Areas. Please see the Journal Overview page on details on how to format and submit your journals.

Question 1: Create a plan 

Using the class diagrams you created for the previous journal, create a development plan for C1. This plan must answer the following questions:

• What work will you be responsible for?

• How will you divide up that work? Write out a list of tasks you need to finish to complete your portion of C1. It may be helpful to think concretely about what it means for a task to be complete. For example, how would you know that the task "implement addDataset" is complete? Something like "create a class representing a course section which accepts only valid sections" is a much more actionable task.

• What date will each of those tasks be completed? This is just a plan, so it is ok if you do not meet these dates.

OPTIONAL: Create issues for each of your tasks. When you are ready to work on a task, create a branch containing the issue number. This will help keep your work focused and provide documentation as you build out your system. You can even reference the issue from commits, other issues, and  pull requests to help you and your partner better understand your changes.

Question 2: Reviewing code

Pull requests (PRs) are common in modern development processes as a mechanism to help ensure the quality of a projects over time as they evolve. Importantly, they provided a point in the development process where developers review code changes before they are incorporated into the main (often production) codebase. The goal of code review is to identify issues like readability, naming, testing,  design, and quality and our code review primer describes what is involved in conducting an effective code review.

Code review for the project. When you create a PR, you will see the message is pre-populated based on our template. Templates help make the review process more efficient and consistent, and many teams (e.g., bootstrap) choose to use templates to specify the criteria necessary for a PR to be accepted for review. We strongly encourage you to follow all of the steps outlined in the template: specifically being sure that you have run prettier, lint, and your tests locally so that your partner can focus on understanding your changes, not style issues.

Learning from others. It can be really informative to look at how well-established teams perform code reviews and how they foster collaboration towards a common goal and interpersonal maturity (as we discussed in the teamwork lecture). facilitate changes (and reenforces the social-technical aspect of SE that we have talked about in class). 

• Link to one example of a PR on a public project and describe one aspect of the discussion that you found interesting. This could include what the reviewer did (or didn't) comment on, the scope of the PR (number of lines/files changed), what was included in the description of the PR, etc.

Question 3: Designing for testability

Note: you may choose to answer either option 1 OR option 2; you do not need to answer both.

Option 1. If you have made reasonable progress on your implementation:

• Provide two links: one to a piece of code that is well tested and one to a piece of code that is not well tested.

• Describe what you used as your measure  of "well tested." Why was one piece of code well tested and the other not well tested?

• Considering the four properties of testability, what design aspects impacted (positively or negatively) your ability to test the two pieces of code?

Option 2. If your implementation is still under heavy development (i.e., not really started):

• Provide a link to either your individual or team class diagram you created in Journal 2.

• Identify one requirement from the C1 specification that your design makes easy to write as a unit test and one requirement that your design makes difficult  to write as a unit test. 

• Considering the four properties of testability, describe why your design would make writing one unit test easy but the other one hard. How feasible would it be to change your design to make it more testable?