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.
Reflect on your team's working style and schedule by answering all of the following questions:
How you prefer to communicate (e.g., discord, whatsapp), how responsive you expect your partner to be (e.g., respond the same day), and how responsive you will be.
Whether you prefer meeting in-person or online.
Your work style. For example, whether you like to get your work done early, or leave tasks closer to the deadline.
Whether you expect to have any weekly meetings outside of lab, and at what time.
The frequency you will push your work to GitHub and open pull requests. In particular, reflect on what a "unit of work" means to you and how you will know it is ready to be reviewed by your partner.
A list of hard deadlines (e.g., large assignments or midterms in other courses) where you'll have less capacity to contribute to the project, and what strategies you will use to ensure the project checkpoints are completed equitably and on time.
Anything else you think is relevant to effective collaboration!
Before your lab in the week following the journal deadline, discuss the working arrangements you each identified separately in your individual journal entry. Working together, create the file teamwork.md in the root of your project repo with your agreement containing your team's combined responses to each of the above questions. This file MUST be committed to your project repo before your lab meeting to receive points for your journal and may be used in cases where teammates are not contributing equally.
Draw a class diagram for your potential C1 implementation. Derive the classes, the major methods and their relationships. It might be simpler to hand draw this diagram and upload it to your Github issue as an Image.
In your lab, compare your class diagram with your partners and agree on a final design. Decide who will be responsible for the different components in the design.
What types of tests did you write in C0: unit, integration, or end-to-end? Will you write the same types of tests in C1? What properties of the system under test (SUT) do you need to consider when deciding on a testing strategy?
Will you use yarn cover locally to identify whether your test suite covers your implementation? What coverage threshold would you be aiming to achieve and why? More generally, what are the pros and cons of coverage-based testing and what implications do these have on your testing strategy?