Unit test examples #17
Conversation
|
@mbareta Should we merge this? |
@bubafinder I asked @MiroDojkic to review and approve. He's back April 1st. |
|
@mbareta Is this an early April Fools joke? |
Haha, I wish I could plan that far ahead 😄 |
| const MAX_LENGTH = 255; | ||
|
|
||
| export function validatePassword(password) { | ||
| const passwordValidator = new PasswordValidator() |
There was a problem hiding this comment.
There is no benefit to instantiating this schema each time the method is called, it can just be done once above the function
| const { isValid, details } = validatePassword(req.body?.password); | ||
| const statusCode = isValid ? 200 : 400; | ||
| res.writeHead(statusCode, { 'Content-Type': 'application/json' }); | ||
| if (statusCode === 400) res.write(JSON.stringify(details)); |
There was a problem hiding this comment.
if (!isValid) seems more natural here - it is functionally the same, but more correctly matches the reasoning, since statusCode === 400 is just a consequence of the result being invalid
| describe('validatePassword', function() { | ||
| describe('successfully validates password when it', function() { | ||
| it('is "Testing12!?"', function() { | ||
| const { isValid } = validatePassword('Testing12!?'); | ||
| assert.equal(isValid, true); | ||
| }); | ||
| }); | ||
|
|
||
| describe('fails to validate password when it', function() { | ||
| it('is not the correct length', function() { | ||
| const { isValid } = validatePassword('Test12!?'); | ||
| assert.equal(isValid, false); | ||
| }); | ||
|
|
||
| it('does not contain uppercase letter', function() { | ||
| const { isValid } = validatePassword('test12!?'); | ||
| assert.equal(isValid, false); | ||
| }); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
While running the tests, this would look like:
successfully validates password when it
is "Testing12!?"
fails to validate password when it
is not the correct length
does not contain uppercase letter
When writing tests, it's often not as good to DRY the code as it is with source code. The worst perpetrator usually are the generic setup functions that are extracted just because a few lines are often used together, but it also applies in the general separation of test cases (drying with describe). The reason for that is the importance of test case readability in human language. That's why some frameworks like ava.js completely eliminate describe - and while I don't agree with the full elimination, I do think it should be used sparingly. E.g.
should return true when password valid
should return false when password length is incorrect
should return false when password is missing an uppercase letter
Here, every test stands as a single readable test, without having to remember the describe context. It isn't a problem here, but with more tests that becomes a bigger issue.
Another reason to not use this is that describe is often very useful for writing conditional subcases of the main case. This is usually a more adaptable approach, compared to "success vs. fail" which always just splits into two. And using those within every conditional subcase ends up with a pyramid of doom very fast. E.g. imagine introducing the success and fail within all of the following:
when using a preview session
should not store the data
should return the new entity
should throw when data invalid
when using a learner session
should store the data
should return the new entity
should throw when data invalid
The above is an example of integration tests, and using describe.each would help there, but the point about success and fail cases as additional describes still stands.
Another change I did was the removal of explicit usage of test data within the test name - it isn't important for the reader to know the exact string tested, what's important is knowing that the password is valid. The rules for password being valid are many, so even putting a specific string doesn't give much info and might be misleading since it could be considered a special case.
I've also reworded successfully validates to return true/false since 1. password is validated successfully in both cases, it's just that the result of that validation is different 2. returning a boolean is actually what we expect in this case, so it is correct to state that - it gives us useful info, since another possible implementation of this function would've been to throw an error if the password is invalid.
Lastly, I've started every test with should - this is not a rule and there are probably differing opinions about this, but using a word like that does help to point people in a consistent direction for the wording of each test.
Not sure if what I wrote here is also something to mention in the antipattern section, since the code does not seem wrong per se, it just seems like it can provide more information if structured differently, at least based on my experience.
@bubafinder I know you already approved, but would like to hear your opinion as well.
No description provided.