I love the AAA pattern! I use it often when teaching to devs unfamiliar with testing.
In your example, there's an argument to be made whether the assertion should be hard-coded as expect(result).toBe('Jay J. Cruz');. As it stands, the test code essentially re-implements the production code, meaning if there's a bug in one then the bug is in the other.
Very true. For a trivial example it seems ok but in a real world scenario you're adding uncertainty.
If the test breaks, now you can't tell if the production code or the test has the error.
The test should have concrete values so you don't have to test the test.
If creating the concrete result is too complex, it's better to run the test once and take a snapshot of the result. Inspect that it is correct and use that snapshot against the production code in future runs.
It took me a moment to understand your point, but now it makes perfect sense!
If I compute the expected value in the test using the same logic as the function I’m testing, the test will always pass—even if the function has a bug—because I’m comparing the result against the same faulty logic.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I love the AAA pattern! I use it often when teaching to devs unfamiliar with testing.
In your example, there's an argument to be made whether the assertion should be hard-coded as
expect(result).toBe('Jay J. Cruz');. As it stands, the test code essentially re-implements the production code, meaning if there's a bug in one then the bug is in the other.Thanks Timothy, great advice. I didn't realize this, definitely something to keep in mind
Very true. For a trivial example it seems ok but in a real world scenario you're adding uncertainty.
If the test breaks, now you can't tell if the production code or the test has the error.
The test should have concrete values so you don't have to test the test.
If creating the concrete result is too complex, it's better to run the test once and take a snapshot of the result. Inspect that it is correct and use that snapshot against the production code in future runs.
It took me a moment to understand your point, but now it makes perfect sense!
If I compute the expected value in the test using the same logic as the function I’m testing, the test will always pass—even if the function has a bug—because I’m comparing the result against the same faulty logic.