[Codelab Issue] Testing Codelab 5.1, Step 6 - Semantics of assertEquals

[hirokihokari]

Describe the problem The dyad signature of assertEquals in JUnit is assertEquals(expected, actual). In fact, when the assertion fails, the error message is:

Expected :[expected]
Actual   :[actual]

The provided code sample lists the arguments in the semantically wrong order:

assertEquals(result.completedTasksPercent, 0f)

, which implies whatever the return of result.completedTasksPercent is the expected value and 0f is the actual value that we're testing.

This doesn't have any negative effect when it passes, but when it doesn't (for example, here I've modified the implementation code to statically return 100f), the error message is indeed:

Expected :100.0
Actual   :0.0

, which incorrectly documents the app behavior as Given 1 Active task and not else, completedPercent of getActiveAndCompletedStats(), Equals 100f

In which lesson and step of the codelab can this issue be found? 5.1, Step 6

How to reproduce? It's not a bug.

Versions No relevant

Additional information I'm not sure if this is the right place to submit the issue about the instruction. Please guide me to a more appropriate place if any.

codelab: advanced-android-kotlin

[JoseAlcerreca]

You are totally right about this and the reason many people ignore the names of the parameters is that the natural way to write an assertion is (UUT, expected). However we should probably change them.