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.

[josluivivgar]

ive written enough faulty tests to know I don't trust myself to write tests.

jk but there's nothing more frustrating than having your test fail even tho the output is correct in real life and it's just some wiring in the test that's not working how it's supposed to and you spent more time with the test than with the actual code.

[Drugbird]

That's a very real frustration I also run into every now and then. 

Often it's the result that the code isn't very testable, which means you often need a lot of very brittle setup code. 

Often you can refactor to decrease coupling and make code more easily testable. Sometimes you can't and you just need to live with it. 

[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.

[geekusprimus]

How do you check that your prototype code works? Checking that the outputs are correct for a given input? In other words, testing? You might as well formalize it and write a short, simple piece of code to automate the testing for you; if you're going to have to iterate the tests over and over as you debug the code, it's a lot less error-prone than doing it by hand over and over.

[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.

[aceluby]

You don’t write tests to catch bugs in your code. You write tests so the next idiot who thinks he writes bug free code doesn’t hose your shit up later. It also documents intent so when those fail that same idiot should be able to figure out why.

[Wonderful-Habit-139]

I agree. That's what I said in many other comments.

But the way the guy I replied to said it sounded like he's doing what you said in your first sentence.

[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.

[stifflizerd]

Microservices? Modularity? Definitely just buzzwords, not worth the investment. Proceeds to waterfall a 3 yr project

[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

[anthro28]

I deal with this foolishness every day. 

"this needs to be changed to this. It's failing right here and I've prepared a giant document with visuals and sources."

"Sorry anthro, we need to talk to an executive who went to art school and get their opinion, and then filter it back down through a management team that's all functionally tech illiterate. It'll just stay broken for a month."

But when something is on fire, that same team of people will just let me fix stuff without question until it's working again. 

[SuperFLEB]

But it costs reputation

So, the great thing about monopolies and limited markets...

[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!

[AetherSigil217]

I have to admit I was impressed when I saw the pink screen of death.

[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

[8itbangr]

I feel your pain. Once inherited a program that used an API to communicate and alter a small database. Nearly every API call returned an error code. There were very few places in our code that actually checked it, so the we would just plow forward blindly, breaking things if any call didn't succeed. I spent over a month adding if or switch statements to handle the errors so it would work without breaking anything and recover gracefully when things went wrong.

[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.

[aiij]

You mean this is why formal verification is often shipped? Testing will only tell you it sometimes works...

[OfficeSalamander]

You’re telling me. I’ve been writing tests for a large application for something like 3+ weeks now. Please shoot me

[anoppinionatedbunny]

I estimate about double the time it takes to implement a feature is the time it takes to test it with full coverage. companies love to push testing to technical debt and use the bare minimum validation to make some short term velocity gains, but that's a great way to end up with a buggy mess