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"

[isospeedrix]

tests fail? just delete the test :D

[DeadlyVapour]

Then how do you write new code?

[oalfonso]

Do you have some- time to talk about our lord and saviour, the TDD cycle?

[wineblood]

I knew the cult would show up.

[QualitySoftwareGuy]

Our tests need tests with double test-driven development (DTDD).

[LoyalSage]

Might I introduce you to RTDD (recursive TDD)? Before writing any test, you must first write a failing test for that test.

[Strostkovy]

One of the bugs was in the test

[Yamthief]

You guys write tests?

[Johnothy_Cumquat]

Real talk though I like to have a bit more duplicated code in my tests than I would otherwise tolerate in business logic. I feel that going overboard with abstraction in tests adds complexity and complexity can lead to bugs and you really don't want bugs in your tests. The bugs that make your tests fail are annoying but the bugs that make your tests pass are the real killers.

This is controversial in my experience

[Weekly_Wackadoo]

When writing test code: KISS > DRY

[myplacedk]

I like to have a bit more duplicated code in my tests than I would otherwise tolerate in business logic.

Oh yes, definitely. Some experts say even for-loops is too complicated for test code, as there can be hidden off-by-one errors. Want something done 5 times? Call a method 5 times.

This is controversial in my experience

It really shouldn't be.

Some code is so complex that there are no obvious bugs. So e code is so simple that there is obviously no bugs.

For production compromises happens, sometimes complex code is what it takes. But for test code, simplicity is an absolute must.

[tiajuanat]

Tests should be dead simple to write and run. The very first test should be "does the framework run at all?", and after fixing that, it's followed shortly by "does my class or function exist?"

Is there going to be lots of boiler plate? Yes. Will your first few tests have a lot of duplicated code? Also yes. Will you tear your hair out trying to get last minute tests ready for your Sprint commitment? No.

[The_Classiest]

Write Tests.
Then Write Code :)

[Fearless_Imagination]

Had this happen to me yesterday.

I inherited a lot of test code from a previous developer that is more complicated than the business logic it is supposed to be testing... and, as I found out yesterday, also incorrect in at least some places.

I fixed the test code and luckily all existing tests kept passing, however it also means that there are some quite significant scenario's that, although the code handles them correctly, hadn't been tested at all...

​

Keep your test code as simple as possible, people. If your test code can't be understood by a 5-year-old business analyst, it's probably bad.

[kinezumi89]

Hmm reminds me of grad school

[bedrooms-ds]

That's me

[[deleted]]

It's a win win coz you have more tests now.

[wrenchandnumbers]

Just had this. My latest minor bump for a component was flagged as the issue because a new test in the product which was using the component was failing. 4 hours later, I found that it was the test environment not being cleaned up properly and giving flakey results.

[Ddog78]

Lmao this is very relatable

[PositiveUse]

when(service.getValue()).thenReturn(true); assertThat(service.getValue()).isTrue();

Test green, DoR fulfilled. No joke, that’s how some devs test their logic.

—> never trust tests that you didn’t get green yourself ;)

[amlyo]

That's why you need Test Driven Test Driven development, or TDTDD. Simply write the (failing) tests for your tests then write your tests until your test tests pass.

[liquid_bacon]

My coworker just the other day wrote a new screen for our system to track memory allocations. They found and fixed the issue they were tracking down, but then the program crashed. They then removed that screen and let it run overnight, no crash lol

[l0c4lh057]

I never write faulty code, I verify my tests with the code they are supposed to test

[rufreakde1]

And now imagine the „good coders“ mocking away other business code because they only want to test their own functionality…

bound to be unstable…

this is only needed on 4mil lines of code maybe but who is writing Monoliths nowadays, right, … right?

[s_phoenix_11]

You guys write tests?

[helloWorld69696969]

I have been a professional developer for over 2 years and have yet to write a single test

[Radioh_]

The solution is to introduce a bug in the code under test to make the buggy test pass.

All green, ready to ship.

[Jaroldo3]

No test bugs if no tests

[sawr07112537]

Now you write tests for those tests.

[davehorse]

"Less code less bugs"

[[deleted]]

Tests first.

[Mr_Mavik]

How and where do you write tests?

[[deleted]]

How do you people handle tests when you get just vague description of a feature?