Task Breakdown (revised):
|Team meeting(s)||18/02/21, 21/02/21||2 hours|
|JUnit Research||24/02/21||2 hours|
|Check Edd's timer code||24/02/21||5 hours|
|Weekly Total||N/A||9 hours|
Weekly meeting takeaway:
In this week’s meeting we had a discussion about more administrative items like deciding project leader roles and QA roles. Additionally, we went through and checked the blogs, I noted that I should be noting the date of each item, so from now on I’ll add a date column to the task breakdown tables. I also noted that a short description of each task is desirable, with bolded titles for easy identification.
For this week I’ll look into how to use JUnit to create module testing, this will be essential later on during development.
Additionally I’ll check over Edd’s timer code once it’s on the GitLab.
I spent some time looking into JUnit as a method of constructing unit tests.
Luckily as it would happen, you can add JUnit as a library with maven just like GSON, meaning that there won’t be any issues with getting external libraries in for anyone.
I found that the only key parts of JUnit that we’ll likely need are “Tests” for the basic structure, and “Assertions” for checking correctness. We can combine these with some custom written testing code that uses the actual methods in the real code to execute robust and quickly repeatable unit testing.
However until we have any more concrete code that might be close to what’ll actually be in the final program I can’t really create any good examples, as they typically use the methods of the programs they’re testing, was well as external parts that need to be tailored on a case by case basis.
Checking Edd’s timer code:
I spent an embarrassingly long amount of time looking over Edd’s code, writing out an accompanying class to give the timer a test drive. It… didn’t really work properly? If you instantiate a timer object, you can’t use it. If you don’t then you can… but it stops functioning after a single timer has either finished, been paused or stopped… which is all that can happen to the timer… Upside is that it does run in the background and the timing is fairly accurate on the first pass. Other things to note are the fact that internal variables and methods are left public, whoops!
I conclude that this section of code needs some pretty major redesigning, but at least the core functionality seems to be buried in there somewhere.
Due to a lack of time this week I’ll likely have to get together with Edd next week and we can spend some time fixing it together.