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.
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.