Java API docs wrote:It is strongly recommended, but not strictly required that (x.compareTo(y)==0) == (x.equals(y)). Generally speaking, any class that implements the Comparable interface and violates this condition should clearly indicate this fact. The recommended language is "Note: this class has a natural ordering that is inconsistent with equals."
Sam Parson wrote: ...develop good test habits for myself, so when my name is on the code I put out, it will not be something I would be ashamed of.
Sam Parson wrote:
So this is where he and I had a bit of a disagreement on. He said I should test the min, max, and middle... For example:
In a range of integers 1 through 10...
His tests would be -> test 1, test 5, and test 10.
My tests would be -> test -2147483648, test -2147483647, test -1, test 0, test 1, test 2, test 5, test 9, test 10, test 11, test 12, test 2147483646, and test 2147483647
Now should I be expected to write tests for every number available outside the boundaries? What if number 1715385483 fails? How would I know it would be a test that fails without writing a test for every single number outside the boundary (also imagine how long these tests would take to execute all at once)? This is something I would hope QA would catch before release to customers.
Sam Parson wrote:
Also, another good video talking about what is actually happening now between devs and QA -> https://www.youtube.com/watch?v=p0O1VVqRSK0 (begin at 32:40 on his talk about the relationship between devs and QA).
OP wrote:what is actually happening now between devs and QA
Sam Parson wrote:...and not actual unit testing or tdd. He said unit testing and tdd is running tests just to make sure it works.
Sam Parson wrote:My mentor/friend was saying this would be more for QA testing and not actual unit testing or tdd. He said unit testing and tdd is running tests just to make sure it works. But running tests outside the boundary scope is more the job of QA testers who should try and break your program. I'd like to think I can automate this somehow, but if pressured for time, managing test methods at the end of every class before deployment would probably cause a headache, and I would leave it to the QA people.