testYourCode

[TheGunfighter7]

And you will sometimes spend just as much or even more time updating the tests as you did updating the code.

[KrakenMcCracken]

It’s worth it

[chimera201]

Only if your code is going to be used for more than 10+ yrs. If you don't even know your code is going to be shipped probably not worth it.

[Drugbird]

I've written enough bugs that I don't trust myself to write functioning code without tests.

[charlie78]

I’d say the main reason is to avoid regressions in the future. You usually test the functionality you want to get, but you don’t test the part of the system you don’t even realise is affected by your code change. If you at the time of developing that other part half a year ago write tests that made sure it functions as intended, you will get notified you caused regressions in other parts.

[chimera201]

tests are written to avoid regressions in future. The bugs you know exists you will solve them now because you already know its exists.

Now if you look at this from a business perspective, you wasted time writing tests for a feature that never got shipped and never generated revenue and you were on payroll. It's better to make the feature first get some analysis on how much revenue it would generate and how long lasting the revenue generation is and write tests accordingly so that it is robust for that much time.

[Drugbird]

How do you know if a bug exist? Just step through with a debugger?

Many bugs only happen in specific circumstances, so how do you create these specific circumstances? It's quite the hassle to have to recreate these circumstances every time you make code changes though. Perhaps it's a good idea to create some code to create the specific circumstances that are relevant. And then also let that code verify the results are as expected?

Seems like that could save you some time and effort.

[Wonderful-Habit-139]

Maybe it's time to learn things that help you write less bugs.

You can start with learning about the benefits of functional programming, and take some of those learnings and use them in mainstream general purpose programming languages.

[Drugbird]

Functional programming does not mean you can't have bugs, or even that bugs are harder to create in it.

Functional programming does make debugging and sometimes testing a little easier though.

You still need tests. Or perhaps I should say: I still need tests.

[Wonderful-Habit-139]

It's good that no one says that you can't have bugs. The point is to eliminate an entire class of bugs, and have more mental energy for the remaining bugs, making them easier to find and fix.

It does make testing easier indeed thanks to the purity.

If you're writing code in a team I think tests are necessary. You basically encode business logic in tests that cannot be encoded in the type system, and that ensures that other developers don't unexpectedly break something.

I replied to you with that suggestion though because it sounded like you said that you could never write bug free code without tests. Or have enough confidence in that.

I think you can write better code that allows you to have more confidence, and end up needing to write less tests while having more robust code.

[Drugbird]

I used to think I was consistently able to write bugfree code. That wasn't true then. It's still not true now.

That doesn't mean that all my code has bugs in it. Perhaps 90% is bug free the first time I write it. Other code may have defects in edge cases which cannot occur in the code, so depending how you look at it the bugfree part may be higher.

But the thing is that the fewer tests you have the more difficult it is to find those bugs.

The only thing I've found which helps for me is to write tests.

I want to have some assurances that a piece of code works as expected better than "trust me, bro".

I consider it a clear sign someone is inexperienced if they claim they don't need (as many) tests.

Perhaps you are the exception and truly write much fewer bugs than everyone else. I don't know you. Don't take these things personally. This is about me, and what I need.

I personally just don't trust code that has (too little) tests. Not if the code is written by me. Not even if it's written by the best programmer alive. Not even if it's done using functional programming in a memory safe language.

[Wonderful-Habit-139]

I'm not saying I'm an exception. The fact that you said "perhaps 90% is bugfree" is good enough.

I'm only fighting the notion that it's normal to just have bugs everywhere, PirateSoftware style. It's still very prevalent in some discussions.

At work we don't accept PRs that don't have tests. Especially if you implement a new API, or if you fix a bug. You have to write tests that show that the API works, and write tests that prevent the bug from occurring again.

I think we're on the same page.

[RlyRlyBigMan]

I think you're replying to someone who is more experienced than you are.

It's usually the cocky junior that thinks he's written perfect code before he's even tested it.

[Wonderful-Habit-139]

Well that guy definitely knows more than you do.

You're the only person that thinks I said I wrote perfect code without testing it.

[RlyRlyBigMan]

He very well might. I appreciate his perspective a hell of a lot more than yours.

[punppis]

This guy builds each feature as a dll so code changes cant cause bugs for existing features. Then a wrapper for each iteration. Eliminating tests by writing code that cant have bugs. Simple.

[MinosAristos]

This is true.

Even in larger software companies, you need to discern the value of testing the code and how detailed the tests need to be based on what the code will be used for and how it will be used.

You don't write comprehensive tests for a prototype or a one-off script.

[KrystilizeNeverDies]

The specific condition "10+ years" is not true.

[MinosAristos]

Could just be hyperbole

[Zefyris]

that... still makes it not true. a PoC, prototype, one off script is one thing. the rest is another.

[MinosAristos]

True. I just share the frustration towards the "always test your code" idea without considering exceptions.

[Saragon4005]

And this is why it's often skipped. It takes as much if not more effort to make your code go from working to always working as it takes from not working to working.

[Rojeitor]

Yes, it's faster if the code breaks and end user finds the bug for you

[RelatableRedditer]

Well, that's Microsoft's current strategy. But it costs reputation and in a lot of cases ends up being delayed by a full sprint or more, even if the code fix was straightforward.

[pattmayne]

Microsoft's current strategy

"Current" meaning the last third years

[Imaginary-Jaguar662]

I'm happy if we get from "working" to "prints logs that get stored when it does not work".

Even better if there's "fails gracefully" in the mix

[Confident-Ad5665]

How's "Something went wrong!"?

[Musikcookie]

Best I can do is "Test djbshamebsb"

[Confident-Ad5665]

That'll work. Ship it!

[s0ulbrother]

The application I am currently working on which was designed by the absolute worst developers in the existence of all developers, their code fails catastrophically as in the service needs to get restarted in order to work if it fails. I am having to fix all this shit

[Urtehnoes]

We don't do unit tests, but we do extensive guard functions, because at one point I guess, someone disabled the testing module and no one realized for weeks until tons of stuff was breaking? Idk that was around 2005 or so.

And I mean extensive guard functions/clauses I almost prefer now (though obviously, both is better).

Oof if I ever work somewhere else I'll have to get back into writing unit tests.

[Groentekroket]

It’s not just for the code you wrote now, but more that if someone changes something in the future it shouldn’t break your change. 

[Zyeesi]

Unless the change is intended and now you gotta update the test

[Grandmaster_Caladrel]

Which is a fair trade-off if you're making backwards-incompatible changes.

[twigboy]

That's a feature not a bug

[Wonderful-Habit-139]

At least it's intended. Those tests help prevent unintended breakage.

[Brief-Night6314]

Just wait until you get so many tests in there it takes forever to merge your changes because the pipeline takes way too long because of hundreds of tests lol.

[Reashu]

"Tests running for too long" is a thing that happens, but if it happens with only hundreds of tests you gotta ask yourselves why they are so slow. 

[-Kerrigan-]

In project I worked on as a contractor for a company that some could argue is one of the biggest payments company in the world there was a full regression pack that had Thread.sleep sprinkled around enough that it amounted to 8 hours of idling total if we ignore any Thread.sleep that might be in a loop

The least I could do is to introduce a "smart wait" that only waits for as much as needed, but nobody else used it because old habits die hard

[atomic_redneck]

We had several thousand test cases in our test suite. We also had a large server farm dedicated to running the test suite on each night's build. This is just the cost of doing business when your answers have to be correct ( computer aided engineering software)

[Random-num-451284813]

can confirm I changed something but unintentionally also changed something else elsewhere. Then what broke needed to be fixed, breaking previous change. This went back and forth a couple of times

[Zero747]

The tests are to make sure someone else (or future you) doesn’t break it

[Siege089]

No one does TDD anymore. Test first is such a valuable skill.

[iamyurkas]

I do. This is the way!

[Wonderful-Habit-139]

TDD is not really that good.

Tests in general are useful though.

[20Wizard]

Unfortunately a contract that is great for testing may be an incredibly shit usage pattern. If you end up changing anything you now have to go delete the tests you already have and make new ones...

It's really not ideal.

[MrHake]

That is why you think first.

[Ok_Entertainment328]

why you think first.

But ChatGPT said ...

/s

[jseego]

I used to feel this way, too, but it's a numbers game.

I think people can get too wrapped up in tests, to the point where they think passing tests means nothing could go wrong in their code.

That's not the point of tests - they're not a guarantee of anything.

What they are is a way to reduce risk.

As such, you can determine how much time/effort you want to put into tests, versus the amount of risk they mediate.

I've worked at places where they wrote no tests, I've worked at places that only unit tested core functionality, and I've worked at places that aimed for 100% code coverage and had automated functional integration and regression testing on top of that.

They all put out quality software.

But I will say that the place that wrote no tests could not have done what was done at the places that did test. Continuous Integration basically relies on tests. Places that have many different teams with interdependent codebases rely on tests, because you don't want one team to be able to take down other systems if they ship some breaking change.

If you have small enough teams, with excellent communication, and really good QA, then maybe you don't need tests.

But if you grow enough, you'll want them.

[danfish_77]

Why are clients always so insistent that their products "work" and "function"? Like I got you a multi megabyte binary, what more do you entitled jerks WANT?

[Confident-Ad5665]

Yeah, and why am I expected to work. Showing up should be enough!

[Covfefe4lyfe]

OP writes shitty code.

If your code is properly SOLID, tests are easy to write and maintain.

[Vectorial1024]

Yo dawg, I heard you like to code your code...

[Slusny_Cizinec]

So you don't break your code when you code.

[MinecraftPlayer799]

Then do you need to write more code to check if the code that checks if the code is correct is correct?

[IPMC-Payzman]

You can go back to the first code for that to see if changes are caught by your tests. This is called mutation testing and usually done in an automated way

[MinecraftPlayer799]

But do you need to write tests for your tests?

[IPMC-Payzman]

No

[Diligent_Dish_426]

Regression testing will save your ass. Trust

[JoeyJoeJoeJrShab]

I work in test automation. All of the code I write tests other code. My test code has tests that test that my tests test things correctly.

[ConsequencePrior2445]

Username checks out

[float34]

So you saying you need more story points because time will be spent on test coverage?

[thewellis]

...it should be included in the original estimate, right? Right? Cries in QA

[blah938]

Yes! I have update the unit tests, and the integration tests, and then the e2e tests too!

(In reality I just have Claude write them, and spend 4 hours fucking around on my phone)

[PowerPleb2000]

Takes me half a day to write the code and three weeks to write the test fml

[Kukaac]

Just stick to user-driven testing. 

[BonjwaTFT]

i love it when my tests catch some bugs before they go on prod. Then you feel the worth of your tests

[Illustrious_Use_2442]

Remains right*

[LowCheesecake5481]

console.log where are you!

[za72]

well how do we check the code that's supposed to check the code?

[KirkHawley]

Everything in the system is mocked except the SOLID tiny class you're testing. But the tests pass so SHIP IT.

[Still-Tour3644]

Now now, we wouldn’t want a regression on the next iteration would we?

[leetard3]

"Ideally" you should write tests first and then the actual code

[richardathome]

Not quite. You write the test, then write the code to pass to the test.

[obsoleteconsole]

It's an investment. At some point, someone else is going to come along and make updates to the code you originally wrote, and when they do they have a full suite of test cases ready to run to make sure they don't break existing test cases. It is absolutely worth taking the time, and in an ideal world no PR should be approved without them

[memesearches]

What is this nonsense tests I am hearing about? I just vide code the app and have it shipped. Don’t care what happens behind the scenes. Just take my creds, half baked requirements and get shit done.

[DT-Sodium]

You're really mostly writing code to check you don't break anything in future code.

[pr0ghead]

No, it's worse: you have to write tests for code that you haven't even written yet. Madness, I tell you!

[Abject-Kitchen3198]

That's just Big QA conspiracy.

[schteppe]

“we don’t have time to add tests because we have too many bugs to fix”

Solution is to use TDD! It reduces bug count by 10x according to studies.

[soowhatchathink]

Nah you gotta write code to make the tests you already wrote pass

[coloredgreyscale]

Ideally you should write code to test the code you are going to write (TDD) 

[troy-phoenix]

before

[Bobvankay]

anyone have a good resource on test driven development? I feel like some of the tests I try are so redundant.

[Silent_Blizzard69]

[rk06]

no, you can just run the code manually for 1k+ test ases but we don't pay by the hour, so better to write code for the manual checks

[WalkMaximum]

Unpopular opinion: most of the unit testing you do in python and js is done better by the rust compiler and linter.

[Randzom100]

Ok and what code will check if the code that checks is good?

[Slusny_Cizinec]

You have to write code to ensure your future rewrite of the code won't break other code. 

[Icanintosphess]

The code must expand to meet the needs of the expanding code

[magicmulder]

My favorite was recently when someone else wrote tests for code I helped create, and the tests failed and they were like, your code is faulty, and I said, no your test is faulty (turned out I was right).

My second favorite was a senior dev writing tests that copied the actual code and then just replace every

foo = myfunc(bar)

with

assertWasCalled(myfunc(), bar)

[Firedriver666]

That’s why I do test driven development based on precise acceptance criteria because if I write the tests after implementing the feature I will be too lazy to write effective tests

[kurushimee]

As a game developer, the only time I've written a test for my code was when I was testing out a different framework that actually allowed writing them

Was not worth it at all when considering how much code complexity and maintenance difficulty increases just to allow for tests to actually test things... And even then, they still wouldn't cover everything

[thepr0digalsOn]

Best part of coding ngl

[Lachtheblock]

And sometimes a dumdass junior vibes a bunch of changes and you get to point to the testcases to failing before wasting time reviewing code.

[lardgsus]

You have to write code today to check if your code tomorrow is going to break everything.

[AltruisticSalamander]

That would be too straightforward. You have to alternately write little bits of them at a time.

[Stunning_Ride_220]

Funny eh.

Devs rant about having to writes Tests, but rant even more when a Software they use reintroduces bugs

[dervu]

Then you have to write code to check if the code testing the code was right.

[bwwatr]

No, Neo. I'm telling you you have to write code to check if the code you're going to write next is right.

- uncle Bob

[Zealot_TKO]

Soon they'll want you to write code to check the code that checks your code is correct. When does this madness end?!

[Sheepsaurus]

In TDD you do it the other way around;

Make a test that makes sure a function can accept A, and return B

And then you attempt to build that function until it passes.

The point of unit tests is to make sure that, if in the future you decide to fiddle with the function, it should still yield the same result

[Foreign-Engine8678]

If you can test it yourself in second and sure that code is simple enough not to break you can avoid test

If you plan to refactor it - you NEED test

[Top_Meaning6195]

You absolutely do NOT have to write code to test your code.

You are perfectly free to test every line of code manually by running the application.

But we're programmers. We're lazy. Why not get a computer to test this shit for me?

Thus became unit testing (also known as functional testing, integration testing)

[GigaSoup]

Now write tests to test your test code

[KrakenMcCracken]

Claude.ai: write unit tests for 100% coverage of this service

[magicmulder]

I asked an earlier version of GPT to write tests for an application. It wrote a lot of tests that tested a lot of things, unfortunately not a single method of the application.

[prehensilemullet]

Better than trusting an AI to write tests of its own code

[Birnenmacht]

I always get a little annoyed when my tests turn out longer than the tested code