3 ms·

This is probably a bad habit, but I've been writing tests so that I don't have to actually navigate though my app, put it in the correct state, and push a butto

This is probably a bad habit, but I've been writing tests so that I don't have to actually navigate though my app, put it in the correct state, and push a button to see if the feature works or not. Writing the test is just faster.

dvt 5y ago
> This is probably a bad habit, but I've been writing tests so that I don't have to actually navigate though my app, put it in the correct state, and push a button to see if the feature works or not. Writing the test is just faster. This is a clever way of solving this problem, and I've ran into it before, as well. Applications where state is very deep (like a game) and you need to verify certain operations on that state is quite tricky. IMO, I'd probably call these integration tests, not unit tests.
Draiken 5y ago
This is one of the major sources of bugs in my experience. People write unit tests that are perfect and pass, but only pass because you give it exactly the right input to make it pass in the first place. Then when running the actual app, the data is not exactly like on the unit test and you have bugs. To cover those scenarios, we use integration/acceptance tests. So I always come back to the same question: then why should I even bother with unit tests? Especially the unit tests that people normalized (test per class/public method). You end up with unit tests that are extremely coupled to the implementation, and without proper integration tests, you can't guarantee it will all work anyways. It only works on a bubble. I believe tests should be much more about the broader behaviors than the implementation details, but TDD and evangelists of today will have you writing tests for every small class you create. I personally still use unit tests from time to time when there are a ton of edge cases on a single behavior that I want to test, but that's the exception not the rule. By avoiding unit tests, or to put it differently making the units tested larger, you get more space to refactor, less coupling between tests and implementation as well as more meaningful tests. Somewhere along the way we lost the meaning of "unit" and it became "class/methods", when it was originally supposed to be more at a module level.
- EdwardDiego 5y ago
  I use unit tests primarily for a) verifying my edge cases (like the old joke goes, "a tester walks into a bar and orders -1, 0, jkhkhkhjkh...") and b) preventing regressions.

dvt 5y ago

> This is probably a bad habit, but I've been writing tests so that I don't have to actually navigate though my app, put it in the correct state, and push a button to see if the feature works or not. Writing the test is just faster. This is a clever way of solving this problem, and I've ran into it before, as well. Applications where state is very deep (like a game) and you need to verify certain operations on that state is quite tricky. IMO, I'd probably call these integration tests, not unit tests.

Draiken 5y ago

This is one of the major sources of bugs in my experience. People write unit tests that are perfect and pass, but only pass because you give it exactly the right input to make it pass in the first place. Then when running the actual app, the data is not exactly like on the unit test and you have bugs. To cover those scenarios, we use integration/acceptance tests. So I always come back to the same question: then why should I even bother with unit tests? Especially the unit tests that people normalized (test per class/public method). You end up with unit tests that are extremely coupled to the implementation, and without proper integration tests, you can't guarantee it will all work anyways. It only works on a bubble. I believe tests should be much more about the broader behaviors than the implementation details, but TDD and evangelists of today will have you writing tests for every small class you create. I personally still use unit tests from time to time when there are a ton of edge cases on a single behavior that I want to test, but that's the exception not the rule. By avoiding unit tests, or to put it differently making the units tested larger, you get more space to refactor, less coupling between tests and implementation as well as more meaningful tests. Somewhere along the way we lost the meaning of "unit" and it became "class/methods", when it was originally supposed to be more at a module level.

EdwardDiego 5y ago
I use unit tests primarily for a) verifying my edge cases (like the old joke goes, "a tester walks into a bar and orders -1, 0, jkhkhkhjkh...") and b) preventing regressions.