These seem useful, but I don't like generating random data in unit tests. If you have known data in your unit test objects, then you can directly test that the results are correct. If not, there is always a danger that you will duplicate the application logic in the test, which then isn't testing that it is the correct logic. You might use random values when you don't care what they are, but then you later add tests that do care, and that's when the temptation to calculate the "expected" value for an assertion comes in.
Also, if a test passes and then fails I want it to be because my last change broke the functionality, not because a new random input exposed a pre-existing bug. (fuzzing tests are a good way of catching missed cases, but are a separate task from unit tests)
In summary on 2.
"Use test object builders to make test setup easy for commonly used objects"
Use random data set will help dealing with edge cases. Hardcoded (expected) results are making test cases less reliable. From my experience, it always made me loose time with hardcoded values.
Great points. To help with generating consistent pseudo-random data, faker.js actually allows you to provide a seed so that the same results are generated every time.
With that you get the best of both worlds: "Random" data generated for you, but also consistent data used for tests so the same test doesn't randomly fail when different data happens to be generated.
For me it depends on what the test is trying to achieve. If the code under test is doing more than it strictly should, then sometimes the tests have to be tied more into inputs and outputs. This can help when that functionality is refactored out, but I think it's important to get some test coverage before a refactor if there wasn't any coverage before, as it's all too easy to introduce bugs when refactoring complex code.
However, I agree completely on your point of avoiding calculating values in tests. Having pre-calculated values that test branching though is ok.
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.
These seem useful, but I don't like generating random data in unit tests. If you have known data in your unit test objects, then you can directly test that the results are correct. If not, there is always a danger that you will duplicate the application logic in the test, which then isn't testing that it is the correct logic. You might use random values when you don't care what they are, but then you later add tests that do care, and that's when the temptation to calculate the "expected" value for an assertion comes in.
Also, if a test passes and then fails I want it to be because my last change broke the functionality, not because a new random input exposed a pre-existing bug. (fuzzing tests are a good way of catching missed cases, but are a separate task from unit tests)
In summary on 2.
"Use test object builders to make test setup easy for commonly used objects"
Use random data set will help dealing with edge cases. Hardcoded (expected) results are making test cases less reliable. From my experience, it always made me loose time with hardcoded values.
Great points. To help with generating consistent pseudo-random data, faker.js actually allows you to provide a seed so that the same results are generated every time.
github.com/marak/Faker.js/#setting...
With that you get the best of both worlds: "Random" data generated for you, but also consistent data used for tests so the same test doesn't randomly fail when different data happens to be generated.
For me it depends on what the test is trying to achieve. If the code under test is doing more than it strictly should, then sometimes the tests have to be tied more into inputs and outputs. This can help when that functionality is refactored out, but I think it's important to get some test coverage before a refactor if there wasn't any coverage before, as it's all too easy to introduce bugs when refactoring complex code.
However, I agree completely on your point of avoiding calculating values in tests. Having pre-calculated values that test branching though is ok.