10
Yes, I agree that randomness shouldn't be part of a testing suite. What you want is to mock any real randomness, to create deterministic tests.
Even if you genuinely need bulk random data, more than you can be bothered generating by hand, you should generate it randomly once, and then use that (now set in stone) data as the "random" input for your ...
4
If your code includes checks for exceptional conditions, your tests should test them, too. Of course, this increases the number of tests, but as your border case checks increase complexity, this is only natural. It is also good practice to test for the uncommon cases, as developers tend to "assume" how the code behaves in these cases, which may ...
4
What you describe is the difference between solitary unit tests and sociable unit tests. The developer writing the code is advocating for sociable unit tests, while it seems like the team's standard is for solitary unit tests.
There are pros and cons to both approaches. There are trade-offs between speed, the scope of the test, the amount of coverage, the ...
4
I agree with @ThomasOwens's anwer as far as you should comply to the companies test strategy.
I disagree with his answer as far as different test types serve different purposes, have different properties and consequences. IMHO it is important to know the differences to be able to implement them for maximum efficiency (with the development process in mind, ...
3
What you are describing seems like the difference between solitary and sociable unit tests. I would have some questions about loading a 45MB database and sending actual mail - the database is quite large and sending email often requires a lot of other pieces. Conceptually, though, it seems like the unit tests are sociable unit tests.
The concerns that I have ...
3
No. Random values in unit tests cause them to be not repeatable. As soon as one test will pass and another will fail without any change, people lose confidence in them, undermining their value. Printing a reproduction script is not enough.
That said, randomized edge case testing and fuzz testing can provide value. They’re just not unit tests at that point. ...
2
Since you're creating a Docker container every time you run a test, and destroy it once the test is finished, the code which creates and destroys the container is, I imagine, in the SetUp/TearDown methods.
What you should consider is how different are those SetUp/TearDown methods from class to class.
If all they do is to call a method which would create/...
2
It depends on your requirements. Unit tests describe how your code works. If you pass in null and it returns the wrong return, write a test for it to describe that behavior. That might be perfectly fine.
If you need to handle those cases, then update code and corresponding tests that describe that new behavior. It may be annoying but those tests will ...
1
In reality, I would probably not test this function in more than one TDD step - chaining three ready-made system functions together isn't particular error-prone, and if it fails, finding the root cause should be done pretty quick with one type of test alone.
However, lets do this for the sake of an exercise. This function consists mainly of two steps (as it'...
Only top voted, non community-wiki answers of a minimum length are eligible
