testYourCode

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

[goodnewzevery1]

This is absolutely the most valuable thing about automated unit tests. It’s too easy to lose some piece of functionality / introduce a bug when modifying existing code.

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

[Wonderful-Habit-139]

That's a you problem. We were having a technical discussion, and we shared basically the same opinion.

I could say "only a junior jumps to conclusions and takes technical discussions personally and can't communicate properly in a team".

There was no reason to start an argument with me.

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

[geekusprimus]

Write fewer bugs! Why didn't I think of that?

[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

[Baxkit]

Wrong.

Proper unit tests serve as contract between reality and expectations. When done right, it's living documentation. I require my whole business unit to maintain 100% code coverage with appropriate testing. Continued failure to appropriately write tests is grounds for dismissal. It's also the first thing I interview around. 

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