4 ms·
We're not testing Java, we're testing your code which is a method to add items to a list. If it passes the tests, great. If there is a bug in the JVM, maybe it
by latchkey 1y ago
We're not testing Java, we're testing your code which is a method to add items to a list. If it passes the tests, great. If there is a bug in the JVM, maybe it picks it up or doesn't. That doesn't negate the need for the test.
The way I look at testing is less about the current point in time. It is about changes over time. If someone else comes along and changes the underlying implementation to a list where sort order is not guaranteed (maybe thinking their version is faster or something), then the tests will fail and that's exactly what you want. You're testing the expected behavior over time and right now, the expected behavior is a sorted list.
Regardless, I don't understand what you're trying to argue or prove here. Yes, testing is hard and not easily won, I already said that.
- lostmsu 1y ago> But if you test for those invalid states, the reasons are expected I am arguing against your claim that this particular suggestion is feasible for anything but toy projects.
- latchkey 1y agoSuggesting that tests are only for toy projects is some weird kind of ego troll thing you've got going. Look inward.
- latchkey 1y agoExactly what I'm talking about: https://erikras.com/blog/final-form-to-typescript https://erikras.com/blog/final-form-to-typescript "Of course, it helped that long ago I had put in all of the legwork to have near 100% test coverage, so I could be certain that the migration did not introduce any bugs."