On February 18th Daniel and I met again with Mr. Lindner. It was the first time we presented some code. The two of us had implemented the domain-model in Kotlin in the weeks before. We wanted Mr. Lindner to have a look at the program code and discuss some open questions.
The implementation of the grade-object became the first main topic of our conversation. We struggled with the question: Can we implement the grade as an immutable object? In the first attend, Daniel and I wanted to use a trick, that had already helped us with the implementation of the history-object. This object contains a list and an add()-function. But to protect the existing object from changes, this function does not really add anything to it. Instead, it creates a different history-object with a new list, built from the old list and the attached entry. However, this design comes with one downside. You have to make sure that no references on the old history-object remain. Concerning history, the costs are low. But for the grade, this method didn't seem to fit.
A handful of good questions from Daniel Linder led us to an unexpected discovery: A fuzziness in the domain-language, that we didn´t notice before. In the ubiquitous language, the word 'grade' has two different meanings. On the one hand, it´s used for the distinct definition of a grade, including the color, the rules and so on. All of those are immutable attributes and therefore base data. On the other hand, the word 'grade' includes the current run or stage of this grade. Here we have mutable attributes, like a list with the days passed in this grade and the current progress inside the grade. So this is transaction data clearly.
At this point, we remembered the rule to always separate base data and transaction data and came to the conclusion, to split our grade-object in two; 'grade' and 'run'.
Accordingly, each run has the reference to one of the grades, to access the immutable attributes. Now our problem was solved: Grade became immutable, run mutable.
The second main topic was the implementation of our tests. Even though some of those tests wouldn't be necessary, we decided to write all of them to get used to it. Again there was a lot we learned from the conversation with Mr. Lindner. He introduced us to the 'Tripple-A-Rule'. This Rule claims, that every test should consist of three parts separated visually by an empty line - Arrange, Act and Assert. While applying this rule to our tests, we soon exposed an interesting exception of the concept. Sometimes we utterly tested the arrangement, leaving out any act.
Furthermore, we wondered, whether we should put all the flat things together in the test itself too. It´s probably rational to capsulate some of the inessential stuff in separate functions, but where should we pull the line? Mr. Lindner's answer to this: When you read the test, it should tell you how it behaves. Leave out everything that doesn´t add information to the reader - Give me the story!