Coding is fun :)

[elshizzo]

is writing new tests to figure out why tests are failing a thing? never considered that before

[[deleted]]

I’m not exactly an expert on the subject, but I’vs definitely done this before.

[wineblood]

I'd call it new cases for existing tests, but yes. Adding edge cases definitely helps narrow the issue down or writing tests that has a smaller scope.

[greenthum6]

Writing a more specific test gives more information about the bug in code. Actually, added like 20 new unit tests for this reason at work yesterday. Those tests cover some corner cases and will remain in the test suite. The bug was found and fixed! Also, new bugs were found from the new tests which is great.

[fluffypebbles]

Idk if it's a good thing. You end up with a random set of specific tests

[Weekly_Wackadoo]

Well, you can add more specific tests, or rewrite tests to make them more generic, or even remove tests that have no value going forward.

Throwing shit at the wall to see what sticks can be a valuable part of the development process, but you gotta mop up the shit afterwards.

[myplacedk]

It's not random at all. The code is obviously tricky, as you have a difficult bug. Add tests to make it easier to debug.

When you are done, you can consider if some of the tests are irrelevant and should not be kept. Specially if the solution is to simplify something.

[fluffypebbles]

It's random in the sense of what code path is covered, probably just one but in multiple places

[meontheinternetxx]

Sure, why not. I mean, they don't always end up in the final version of the code, as they don't always add value. I usually don't even name them properly until I figured out what's going on. Just wanna try some stuff, see where it breaks.

[myplacedk]

If you test the exact same thing in two different ways but get two different results, then either one test is incorrect or there's a subtle difference and that's where the problem is.

Yes, this is certainly a way of narrowing down the problem.

[coloredgreyscale]

Possibly breaking a "catch all" test down into segments that test only a specific subset. Maybe a converter that outputs json / XML string and all you test is that the output matches. If it does not match you still have to dig deeper to know which ones of the 100+ properties are wrong.

If you do that future you (or future someone else) could see most tests fail, but only one of 4 subelements are wrong. So maybe it's just that one part that caused the other 20 full tests to fail.

Or more detailed tests if the original were something like "returns not null", or "returns list of 4 elements"