4 ms·

> Unit test thus get written for part that we absolutely want to be maximum certain of that it works correctly. I hear this kind of rhetoric a lot, but rarely

by pards 8y ago

> Unit test thus get written for part that we absolutely want to be maximum certain of that it works correctly. I hear this kind of rhetoric a lot, but rarely do I hear of code that doesn't need to work correctly.

poopchute 8y ago
Code robustness clearly has different priority levels though. A graphical error is much less serious than a part of your code that could nuke your server.
- Klathmon 8y ago
  Except that's not a hard rule (not that you implied it was). A graphical error that prevents users from being able to use the application at all can be basically the same as server downtime in terms of impact to the end user.
cies 8y ago
If the e.g. scheduling code is messed up, and we find out 5 weeks in, then there is a lot of damage. We need to call all parties to review their schedules with them. On the other hand if the code responsible for the styling of some menu is not working correct, the functionality may still work, and once we discover the bug we can simply fix it. > rarely do I hear of code that doesn't need to work correctly. So there are different grades. That's why I used the word maximum. The cost for these unit test should pay bank, even during the dev't phase, IHMO. There are often areas in a large code base for which this hold true, and often they can be identified as such beforehand; then writing these tests should be a priority.
Fradow 8y ago
The difference is not between code that need or doesn't need to work. The difference is having code for which having some bugs is acceptable, vs having code for which bugs are not acceptable. There is definitely code for which having some bugs is acceptable: think about some small feature that the user can totally do without. I had to do one recently, and bugs were acceptable, as long as it was shipped in time, and working for the client specific devices. That code shipped with no automated test (testing is done manually), and a few known bugs not worth solving. On the other hand, anything that touch core features must be tested.
- bpicolo 8y ago
  > That code shipped with no automated test (testing is done manually) An issue with that is bus factor when it needs to be changed in the future. What if the original dev isn't around any more?
  - Fradow 8y ago
    There is a test plan, and specs. Acceptance tests (manual) weren't even done by a dev. Also, the code has been reviewed and is documented. Bus factor really isn't a problem in the instance I was talking about. In fact, the original dev won't be around in a few months, and that's fine. The rest of the team will be able to modify the code.

by pards 8y ago

poopchute 8y ago

Code robustness clearly has different priority levels though. A graphical error is much less serious than a part of your code that could nuke your server.

Klathmon 8y ago
Except that's not a hard rule (not that you implied it was). A graphical error that prevents users from being able to use the application at all can be basically the same as server downtime in terms of impact to the end user.

cies 8y ago

If the e.g. scheduling code is messed up, and we find out 5 weeks in, then there is a lot of damage. We need to call all parties to review their schedules with them. On the other hand if the code responsible for the styling of some menu is not working correct, the functionality may still work, and once we discover the bug we can simply fix it. > rarely do I hear of code that doesn't need to work correctly. So there are different grades. That's why I used the word maximum. The cost for these unit test should pay bank, even during the dev't phase, IHMO. There are often areas in a large code base for which this hold true, and often they can be identified as such beforehand; then writing these tests should be a priority.

Fradow 8y ago

The difference is not between code that need or doesn't need to work. The difference is having code for which having some bugs is acceptable, vs having code for which bugs are not acceptable. There is definitely code for which having some bugs is acceptable: think about some small feature that the user can totally do without. I had to do one recently, and bugs were acceptable, as long as it was shipped in time, and working for the client specific devices. That code shipped with no automated test (testing is done manually), and a few known bugs not worth solving. On the other hand, anything that touch core features must be tested.

bpicolo 8y ago
> That code shipped with no automated test (testing is done manually) An issue with that is bus factor when it needs to be changed in the future. What if the original dev isn't around any more?
- Fradow 8y ago
  There is a test plan, and specs. Acceptance tests (manual) weren't even done by a dev. Also, the code has been reviewed and is documented. Bus factor really isn't a problem in the instance I was talking about. In fact, the original dev won't be around in a few months, and that's fine. The rest of the team will be able to modify the code.