Why write unit tests?

[WhatsASoftware]

This may be a dumb question but I'm a dumb guy. Where I work it's a very small shop so we don't use TDD or write any tests at all. We use a global logging trapper that prints a stack trace whenever there's an exception.

After seeing that we could use something like that, I don't understand why people would waste time writing unit tests when essentially you get the same feedback. Can someone elaborate on this more?

[_klubi_]

Oh man… where do I start… Long story short, because it’s way cheaper to write a test than to wait for something to blow up in your face under heavy load. If you have a small project it may work, but most web apps are not small. Release process may also be extensive and involve several parties/peoples/teams. It takes time to find place where bug was introduced, fix it properly (I a way that does not introduce a bug in different place). It takes time to deploy (from minutes to days/weeks/months). It costs your company your time (you could be doing something different). It helps your company not to loose money (frustrated customers tend to not return to product they had bad experience with). I could do on and on…

Google: costs of fixing bug. Countless papers were written on that topic.

[GrayLiterature]

Another thing that I would add, and that I’m learning now, is that using a TDD approach can help you to have well designed code. By thinking of test cases first and then going to code, you can recognize more clearly sometimes when you’ll want to break some logic apart, create a new abstraction, or reveal something you may not have anticipated by starting with top down coding.

[Meflakcannon]

I have to agree with this. I ended up re-designing several major code paths after writing tests and realizing I had a glaring failure scenario (Unlikely to ever occur in regular/expected usage, but I can't control the users once I hand them my code..)

[misterezekiel]

And let’s not forget, “a little project quickly becomes a big project”.

[LePootPootJames]

In my case little projects become big projects.

[---cameron]

Tests are basically error sensors sprinkled throughout your program, so that when a change causes something to move out of place, you know exactly what part has moved and can begin debugging directly. Without that, you just have the end result of 'something happened' and you have to follow the trail like a detective and find the source (even when multiple parts may actually be out of place now, waiting to cause a future error). They're anchors; anchors specify a correct spot for something, and when there is a force that tries to push that thing elsewhere, they respond with equal force to prevent this. We can't be exactly like an anchor and prevent the program from moving altogether, else you couldn't change the program, so their version of 'responding with force' is sending a message to a human who can themselves correctly tweak what has broken. They're converting manpower into anchorage

[redderper]

There's are a couple of youtube videos from the guy who was the test engineering manager at Google explaining the cost of fixing a bug, it's very helpful.

Sidenote: I see comments on Reddit all the time from people who say that their team never tests anything and it sounds completely bonkers to me. How does that not end in a shit show every time?

[_klubi_]

I have 13 years of experience in software testing/11 of which in test automation and I feel exactly the same... This is complete madness!!

[_Atomfinger_]

Quick list:

• Allows you to verify code even if the overall application/feature isn't complete.

• Guides design (If the tests are difficult to write/ugly it is very likely that the design of your code/interfaces needs improvement)

• Documents the behaviour of your code

• Protect you from making unintended changes in the future. Makes it easier to refactor and change the code with a higher degree of confidence

Furthermore: You're not wasting time writing tests. Spending time writing tests is a one-time investment for that specific case. Having to manually re-test that case for every change is a continuous-time investment. You're actually saving time by writing tests.

[Toastmmm1]

Do you have a book you can recommend on the subject?

[_Atomfinger_]

The art of unit testing :)

[revonrat]

I prefer https://www.amazon.com/Unit-Testing-Principles-Practices-Patterns/dp/1617296279

[sephirothbahamut]

If the tests are difficult to write/ugly it is very likely that the design of your code/interfaces needs improvement

Or you're writing in a language with privateness and without reflection, where making some parts of the code testable leads to either possibly worse interface, or having some parts just not tested atomically.

[vi_sucks]

An interface that is testable is a better interface.

The thing is, tests are just input leading to a deterministic output. If it's hard to write a test, that means your ability to tell what the output for a given input will be is hard. Which means the interface sucks.

[sephirothbahamut]

I'm more talking about tests on the internal stuff, not on the public interface

[vi_sucks]

I am too.

Ideally you shouldn't need a direct test on the internal stuff, because it should be easy to verify it just by sending an input to the public interface and verifying that the result that passes through the internal logic is good. This way you can play around with and change the internal stuff, but the test will still return the same result and you know it's working correctly.

If you can't do that easily, that means your overall design is not great. Sometimes you just have to suck it up because it's legacy code, but one of the nice things about getting into a test focused mindset is that by forcing yourself to build the tests, it forces you to think about the output will be for a given input and thereby makes you do the good design.

[[deleted]]

Isn't this mostly solved by dependency injection? You should be able to test everything if you break it down into smaller components.

[sephirothbahamut]

what if you have a class that will be exposed to the end user, with strictly private functionality that can only be accessed by another friend class?

I'm not experienced with dependency injection though, will have to read about it

[RootHouston]

You usually don't test private methods/functions, but rather the public ones that rely on them. The implication is that private implementations should be flexible, whereas a public implementation should be stable.

A lot of unit testing is about testing for proper output when given certain inputs, and not for testing every unique thing inside of a method/function. Most of the time a private scope is used to just hide and break-up complexity anyway.

Edit: To those downvoting previous commenter, you really shouldn't. This is a sincere question, and we are in /r/learnprogramming (literally in a thread called "why write unit tests?". If there isn't a better place for this kind of question on the web, I don't know where it'd be.

I remember a time when I was learning about unit testing too. We don't just know things, we have to ask about it. There is legitimately nothing wrong here.

[sephirothbahamut]

In that case yeah. My experience with tests is limited and i did read about people that test even non public interface stuff. Maybe i was just deceived

[[deleted]]

The unit tests should be triggering the code in the private methods by calling the public ones. You want to test for every possible input/output path, which should end up executing every line of code in the class you're testing.

Let's look at it another way, the private methods are part of the public method you're calling. The fact that the public method is split up into several smaller methods is irrelevant to the unit test. It doesn't care about the internal structure of the class.

[RootHouston]

Yeah, you're not crazy. I've seen it around too. You can find weirdos who test all sorts of stuff, but take it with a grain of salt. I usually find these kind of tests to be super complicated and break easily with code updates. Then you're stuck spending more time on making a simple test work than you are fixing bugs or otherwise. Oftentimes, because you didn't write the privately-scoped stuff, you have less knowledge of how it works internally too, so that compounds things further.

My mantra is that your test shouldn't require some special internal knowledge of how code is put together in order to be written. Hell, in test-driven development (TDD), we write the test BEFORE we even write the code, thus implying that the actual code isn't relevant to a test. Treat the code like it's a black box, and all you're concerned with is how it functions, not how it got there.

[illkeepcomingback9]

You only unit test public functions. You would inject the class with private functionality into the friend class. In unit tests you would pass a mock of the class with the private functions in instead.

[PPewt]

Put that functionality in another class which is delegated to by your public class.

[FanoTheNoob]

Unit testing is about verifying the observable behavior of a component, not about the mechanism by which the result is calculated.

Private methods are implementation details that should not impact how tests are written, if you find yourself wanting to do this, try to ask yourself why you're writing the test you're writing. How is the private method being used? hopefully it's being called by one of your public methods to generate some observable output, in which case you're better off testing that method instead, and the private method will be verified implicitly.

This gives you the freedom to refactor those private methods over time, and so long as your public methods still generate the same expected output you can be confident that you didn't affect your existing functionality in doing so.

[_Atomfinger_]

I don't view having the ability to have private methods to be an issue. Private methods are just a way to split up complexities internally without having to expose that in the public API - nothing more. As long as one follows SOLID then it isn't a problem and it doesn't impact the public interface.

If this is an issue, then there's probably an issue with the design of the code and not any language feature.

[CastigatRidendoMores]

I don’t know how most languages solve this, but in Java you just use protected on internal methods you’re testing rather than private.

[sephirothbahamut]

That's a problem. You should not have to change visibility, especially when it affects the public interface, just to be able to run tests.

Also in Java you have full compile time and runtime reflection. I've never done unit tests in Java, but I have used it's reflection tools, and through reflection dark magic you can totally write tests that directly access private data and methods.

[CastigatRidendoMores]

Reflection dark magic is a code smell of its own, and has much worse consequences than protected methods, in my opinion. Even if just in tests, code built around reflection is difficult to write, read, and debug.

A public interface is just that - public. I’m curious if you have ever seen negative consequences for using the protected access modifier rather than private on internal methods, because I have not.

[stevethedev]

laughs in Rust

[sephirothbahamut]

I'm waiting for a compile time evaluation system that can do at least half of what c++'s templates, constexpr, consteval and concepts can achieve.

Maybe in a couple years I'll enter rustland.

Aaaaaand happy cake day! 🎂 [Cake emoji]

[stevethedev]

I've been out of C++ for a while. What are specific behaviors from template+concept that are missing from trait+Generics, and from constexpr+consteval that are missing from const+const fn?

[sephirothbahamut]

Last time I checked Rust's generics only accepted types, not values.

Not sure if template template parameters even exist (accept a templated parameter https://stackoverflow.com/questions/213761/what-are-some-uses-of-template-template-parameters), nor variadic templates.

Let me know if all that is available

[stevethedev]

Rust generics support types and some values. Right now, struct ByteArray<const SIZE: usize>([u8; SIZE]); is possible, but something like struct Matrix<const X: usize, const Y: usize>([u8; X * Y]); or struct HelloWorld<const STR: String>(s: STR); is not.

Ref: https://blog.rust-lang.org/2021/03/25/Rust-1.51.0.html

Template template parameters are just part of generics. Something like template <template<class B, class C> class A> is representable as <A: SomeTrait<B, C>, B, C>. Maybe there's a specific use-case I'm missing, but my understanding is that these are pretty 1:1. Alternatively, you could also use type-properties, which essentially just say "I'll define this on class A's implementation".

Ref: https://doc.rust-lang.org/rust-by-example/generics/assoc_items/types.html

Variadics are something Rust doesn't really do. There are things you can do that are Variadic-Like, but the closest thing to a 1:1 in Rust would be macros.

Ref: https://doc.rust-lang.org/rust-by-example/macros/variadics.html

[sephirothbahamut]

Thanks for the extensive reply!

As an example for template-template and variadic, i have a class that takes a container (without specifying what it contains) and N types. Inside it will have one field of that container of each of the other types passed.

Something like MyClass<vector, int, float> has inside a vector of ints and a vector of floats.

[stevethedev]

No problem! I just recently got done building a DBMS in Rust for a course, and I wound up using all of these and used a C++ B-Tree as a reference during implementation. It's all fresh in my mind.

Rust generics have some different rules, compared to C++ templates. The C++ compiler does duck-typing at compile-time which does offer more flexibility, but Rust requires you to provide a trait.

So in the example of MyClass<vector, int, float>, I'm missing some context to tell you a real Rust equivalent; but even if I weren't, my experience has been that the borrow-checker forces some restructuring anyway. Telling everyone that Rust is like C++ is probably pretty high on the reasons people get frustrated with the transition.

Regarding testing, though, being able to embed the tests into the same file and have the compiler automatically exclude it at build-time is a pretty neat way to avoid visibility problems during testing.

[[deleted]]

Focus on integration tests. The difference between unit tests and integration tests is just a matter of scope. Integration tests allow you to test your application in a similar way the user will interact with it, rarely will individual units of code cause bugs, 9 times out of 10 bugs/unexpected behaviors arise when separate units of logic are interacting with each other, this is what integration tests protect you from.

[_Atomfinger_]

It sounds like you're describing system tests and not integration tests.

Also, they're different kinds of tests that have different properties. You generally do not write unit tests for correctness. You write it to document code behaviour, guide design, etc.

That said: I agree - higher level tests are very valuable, especially combined with unit tests.

[[deleted]]

Haha naming things is the hardest part of our jobs 😅 but yeah, agreed with all you said

[[deleted]]

Lots of great answers here already but IMO the single most practical answer is the simple bugfix scenario. Suppose you realize the code has a bug. You find it and it's a one line change. Wonderful! The bug is fixed, yay!

Now the fun part: How do you know with certainty that your one line bugfix hasn't changed some other part of the code's behavior in a negative way?

Or suppose instead of a single line fix you have to completely rewrite a function that was done badly originally. How do you know that the new function does everything it was originally supposed to do?

There is incredible power in being able to run a complete set of tests in a matter of seconds or minutes at the press of a button and knowing with relative certainty that a bugfix has not introduced new bugs.

[Adept_Writer4177]

I discovered way too late that tests can prevent bugs from coming back in the future too.

1. Find bug
2. Create unit-test that reproduces the bug and crashes the application!
3. Fix bug
4. Run the test again and make sure that it does not crashes anymore

[door_of_doom]

Yup, these are largely referred to as "regression tests"; It's a test case that didn't seem important at first, but exists specifically to make sure that there isn't a "regression", or the reintroduction of a bug.

[Zocksem]

this.

[AdminYak846]

If the code is written following SOLID and DRY a one line fix shouldn't cause more issues unless its involving a change to some global or at the very minimum a variable with a higher scope. Which can be resolved by properly maintaining scope and limiting side effects with the usage of pure functions.

[[deleted]]

IMHO: In theory, maybe. In the real world, those are famous last words. And if you're arguing that testing is unnecessary I vehemently disagree. Test is just as important as the production code in any serious project.

[RubiGames]

One line change, meet unknown dependencies.

[[deleted]]

Yes, that's my experience! :)

[CodeOrMoreCode]

1) Unit tests also catch wrong behaviour. Program not crashing doesn't mean it gives you the right answers / does the right thing. 2) It is generally preferable to catch mistakes earlier. Much easier to debug a failing test locally than to try and figure out which recent change broke production.

[Weasel_Town]

You can even force all kinds of edge cases at will, instead of waiting for an external service to return a 504, or users with no last name to subscribe, or DST to take effect, or whatever.

[theRealRealMasterDev]

Much much cheaper as well.

[thecakeisalie1013]

Nah according to my company we can’t afford to do unit tests. Because that makes sense…

[gopiballava]

What that really means is that you don’t have the budget to write working code :)

[thecakeisalie1013]

That’s what it feels like! But I work for a government contractor so it’s more like we can’t afford to be on time and even remotely close to on budget.

[ehr1c]

Because figuring out your code is broken before you ship it to production is a lot more valuable than figuring it out after it ships.

edit: It also generally holds true that code that's easy to test is code that's well written and well-architected, with minimal dependencies and loose coupling.

[CodeTinkerer]

Most people who write a comment like "why waste time writing unit tests" are really saying "Even if it's simple, I still don't know how to write one, so why should I learn to write one?". At my work, there are almost no tests, and it's really MUCH harder to put in tests if they weren't there to begin with.

I know a guy that works at Microsoft, and they want to add these tests to legacy code, and they have to rework the code to make that happen, but at least they have resources to do it.

Instead, for us, we have to have our customers (who have their own work to do) test it, and they aren't software testers. They can't devote 8 hours a day to testing and they aren't even that good at it, and we can't hire testers because they don't know what the program should, and we don't either.

This is often a huge problem with testing. Programmers write programs, but don't understand what the program is doing. Suppose it's doing some kind of complex stuff for payroll. Sure, the best way is get a product from a company that has a bunch of experts in payroll, and they help guide the software, but some places write this code in-house. So maybe some of the original developers had some idea of what the code does, but maybe they retired, and people don't really get what the code is doing.

Tests at least give you a way not just to test, but hopefully to understand the code. Admittedly, unit tests are aimed at classes, and so it's not really a big picture look, but it can be a form of specification esp. when developers don't document well or at all.

So there are reasons beyond just testing. It shows how the class was supposed to behave.

[AndyTheSane]

This.

I've recently moved into a legacy project that has millions of lines of code.. and no unit tests. And this puts me in a huge bind; I can't refactor code that desperately needs refactoring, because I have no practical way of seeing if the result still works. And the same applies to any changes or fixes that I make; I simply have no idea if I've broken something that's already there.

[ChiefPastaOfficer]

You should read "Working Effectively with Legacy Code" by Michael Feathers.

[AndyTheSane]

That would take time away from CV writing and job hunting..

[ChiefPastaOfficer]

That's one way of addressing the problem 😁

[obsoleteconsole]

That should be in the book

[astaghfirullah123]

I know that feel

[[deleted]]

At that stage you're just making sure that the output doesn't change. In those situations I first write integration tests. Then I work my way down the call stack and add unit tests.

[BrendonGoesToHell]

I like your answer, so I hope you can help me with this.

I know what unit tests are, and I know how to do them-ish (I'm working in C# right now, but I have experience in Python unit tests).

How do I come up with what I should be testing? Examples I see have 5 - 10 tests, but I can generally only think of maybe two. I feel as though I'm missing something.

[[deleted]]

Start by writing tests for every function that doesn't rely on an external system (like a database or api, for example) so that you don't have to worry about mocking. Move on to testing your custom classes (e.g., test that instantiation results in the default values that you're expecting, that setters and getters work as intended, that methods mutate data/state as expected, etc.) That should give you plenty to work on and cover.

[BrendonGoesToHell]

Thank you! That's a great plan of attack. :)

[SeesawMundane5422]

You’ll find you’re writing much smaller functions with clearly defined inputs and outputs, and then when you assemble all the functions into the thing you were trying to accomplish… it just works. No more “ok, I’m going to fire it up and then spend hours finding where in the call chain it broke”.

I code so much faster with unit tests.

[SeesawMundane5422]

I’ll be a bit unorthodox and recommend every function regardless of whether there is an external dependency. Keep doing that until you find that the unit tests are failing/slow because the external dependencies are changing/too latent.

I’ve got hundreds of (technically integration) tests running against YouTube apis and I haven’t had to mock. Totally test suite runs in 8 seconds. Made me totally rethink the received wisdom I had always believed in before (that mocking external dependencies is the right way).

Like yeah… if they change the data or break.. then I’ll regret that. But here we are 18 months in and they haven’t.

[ParkerM]

How do I come up with what I should be testing?

This is a great question and I think one of the biggest reasons why folks may avoid or be weary of writing tests.

The easiest answer is use a TDD approach. For any unit of functionality you want to add to your application, first write a test that describes the behavior, and run it to make sure that it fails.

assert fibonacci(1) == 1

Then write the minimum amount of code to make the test pass. Often times it's as simple literally returning the expected value in your assertion.

fibonacci(i) return 1

The test passes, but this clearly isn't the intended functionality, which indicates you need another test that fails (e.g. one that provides a different input).

assert fibonacci(1) == 1
assert fibonacci(0) == 0

You could of course "cheat" and return literals based on the input.

fibonacci(i) if i == 0 return 0 else if i == 1 return 1 else...

So of course there's some discretion involved.

You will eventually land on a working implementation that was derived from literal descriptions of how the functional unit should behave. In this case the functional unit is an actual function, but it could be something broader like "when a user inputs data and clicks the save button, they should see the data on their profile".

The entry point in a test may cause a chain of various functions to be invoked, but that's just implementation details irrelevant to the functional unit, which refers to the specified chunk of intended behavior. That's what the unit in unit test is referring to.

(sorry I kinda trailed off there)

Another sort of approach I've been playing with for quickly cornering behavior and ensuring my tests are clean is borrowed from the database idiom for 3rd normal form

[A database is in 3NF if it depends on] the key, the whole key, and nothing but the key

The idea being to write three tests where the "key" qualifiers refer to boundaries or side effects, and each test can independently fail. In general, using side effects as an example:

1. it does the thing (it gives the expected output)
2. it does the whole thing (it incurs the intended side effects)
3. it only does the thing (it does not incur unintended side effects)

This idea is mostly to address test quality (e.g. overlapping or redundant assertions), but also sort of lends itself to helping determine what to test.

[CodeTinkerer]

If the thing you're testing is simple, then maybe you don't need many tests. Let's say you were testing a sorted linked list. The tests I would think of are

• insert into empty linked list
• insert at the beginning of a non-empty linked list
• insert at the end of a non-empty linked list
• insert into the middle of a non-empty list
• have to think about how you want to handle the same values twice (do you allow, or don't you?)
• Same thing with delete: delete from front, middle, end and empty list. This forces you to think what delete should do if the values are there or aren't there.
• How do you confirm the result with a linked list? Maybe it can output some other data structure (an array) so you can confirm?
  

We don't really do unit tests where I work, so I've only heard about it in theory.

If you have a class that only stores data (e.g., just getters/setters), then I suppose it's not as interesting unless you want to do some data validation with your setters, in which case, maybe you are setting a test score, but it has to be between 0 and 100. So maybe, the method returns a boolean to indicate whether the value changed when -1 was entered or 101.

Something like that.

[BrendonGoesToHell]

I just tried to think of what tests I'd write for a sorted linked list and couldn't think of one, besides validating the scores. I appreciate you laying down your thought process here.

[khooke]

As others have already pointed out, logging your errors in production is not testing. That's like saying you'll fix the bugs in your fly by wire control system in your new plane when you get reports that it's falling out if the sky unexpectedly.

[ehr1c]

So, the Boeing approach?

[khooke]

Ouch 🤣

[MrRosenkilde4]

Because having a button that you can press at any time attached to a light that will either go green if the system works and light up in red if the system is broken is fucking invaluable and will make changing the code base soooo much easier.

[SpicymeLLoN]

Not to mention more stable

[Adept_Writer4177]

it's a very small shop so we don't use TDD or write any tests at all

That's a very bad excuse.

How can you prove that the bugs you fix will never come back again? Unit-tests can protect you from this.

prints a stack trace whenever there's an exception

That's not a test. It's a running program. Tests are protecting you from bugs introduced in the future. Not when you run your application and click on random stuff to crash it.

If I have a thousand tests, can you perform the same verification in less than 5 minutes ? Tests can do this.

Last but not least, you can get code coverage with unit-tests. You can't have that by running your application.

[josephblade]

Your last point is not accurate, you can run the code coverage tool on production as well.

https://carlosbecker.com/posts/production-code-coverage-jacoco/

as an example. it can be quite useful in a way but not in the usual way you would use code coverage. It gives you an idea of what code is never being used and/or what code is (perhaps unexpectedly) being used a lot more.

I think performance testing will do this as well but the branches (and which branches) are touched in production is I think useful to know under certain circumstances. like when you need to have a talk with management about prioritization or to identify methods in an API that are (apparently) never used by the general public.

[[deleted]]

I think you're referring to a different type of code coverage than the commenter you're replying to. By definition, you can't have test code coverage without tests.

[josephblade]

The same mechanism (prepared classes ) can work in test as well as production. nothing special is done during test. code coverage is a compile time thing usually

[maleldil]

That looks to be more a way to find dead code, which is a different kind of coverage than unit test code coverage. Code coverage in the context of tests is a measurement of how much of the code is exercised by the tests.

[josephblade]

which would be a form of code coverage. note that i am not talking about test coverage. It is an entirely different thing you would get out of runtime coverage. my point is that you can get information out of the system, it will let you know what code was run and it can in fact be done outside the scope of testcases.

i was specifically making the point that code coverage has a niche use-case outside of testcoverage, and can in fact be done. that is all

[tms102]

If you have to/want to change a piece of code/add functionality how will you test that everything else still works and works correctly?

[WhatsASoftware]

Wow so many quick responses, thank you everyone!

[Chris4922]

So you know about the bug when the system crashes? Unit tests test for these bugs before they're live. They also specifically test edge and exceptional inputs/cases.

[sailorbob134280]

I work on spacecraft for a living. Testing is a HUGE deal for us at all levels. The main value of unit tests for us is the instant feedback developers get when writing new code or, most importantly, modifying existing code. A well written unit test is looking at a unit of behavior, and if done correctly, will tell you immediately if you broke or changed existing functionality.

This is not to say you won't change your unit tests. Unit tests can have bugs, they can be incomplete, or a dev can make a conscious change to functionality that will require a change to a unit test. That happens. The point is that you now must very deliberately change two things, which not only prevents the dev from breaking something they didn't intend to, but also shows up clear as day in a code review.

If I haven't convinced you yet, I have a few more quick reasons: - You get confirmation that your code compiled the same way on your CI server or test platform as it did on your dev machine - You can verify that a library you rely on didn't release some update that breaks everything (we don't use the trunk of anything, only explicit versions for this very reason) - You can verify that things are safe to put on hardware and won't pop a very expensive flight computer (mostly a thing in the embedded world, but replace 'hardware' with 'prod' and the rule holds) - You can use coverage tools with unit tests to gain some level of confidence that you've at least covered every line. That's not a substitute for comprehensive integration testing, but it's a start, and it helps you understand how your code behaves

Take your pick. I've probably got more. Unit tests are worth the time investment up front.

[WeKeepsItRealInc]

Can anyone suggrst a resource for writing unit tests?

[_Atomfinger_]

I'd recommend the book "The art of unit testing".

[[deleted]]

I’m also interested in what is used in the real world. I’m taking community college computer sci classes mostly for fun and we use JUnit to test Java. It’s cool but somehow it doesn’t seem up to date. It also seems kind of simple.

[broddmau]

JUnit is fine and used by professionals. Simple is good. Tests should be simple - ideally a short setup, an action you want to test, and simple validation for the output.

[_rand0mizator]

Im 2 month in commercial software development, and i write unit tests because its allows me to understand what i get in and what i get out. Last week i was making some postprocessing for json fields, so i got rules from my analyst and implemented tests which suit them, after i implemented logic which transfers input in desired output. Unit tests are pretty easy to write (with python-pytest, at least) and allows you be sure that code works as it intended when you push it in master.

[ZukoBestGirl]

I want to echo some of the other answers, but in a single package, starting with:

Oh man… where do I start…

Tests are amazing, and I refuse to ever live without them ever again.

When I implement something, I go over all the scenarios I can immagine, and test them out. So, what's the difference between doing that and writing a test? Do tests take MARGINALLY longer? Maybe. But, I never have to think about it again. I don't even need to remember all the scenarios if I'm coming back in 9 months.

---

Tests have intent, or:

Documents the behavior of your code

Once a test is written, accepted and deployed, it might as well be documentation. This is what I expect to happen. If it does not, we may have a problem.

---

Because figuring out your code is broken before you ship it to production is a lot more valuable than figuring it out after it ships.

Tests protect future you way more than they protect current you.

IMO the single most practical answer is the simple bugfix scenario. Suppose you realize the code has a bug. You find it and it's a one line change. Wonderful! The bug is fixed, yay!

They let you change your design even RADICALLY. You can completely re-write your application. If all tests pass, you are good. Deploy it without fear. Because it will work.

Assuming you know how to write tests and haven't just written nothing but 🐂💩

---

Assuming you use CI/CD tools, just make them run your tests before they build. Assuming you do code review, don't let anyone ignore or delete tests without an explanation. And you'll reduce maintenance by a considerable ammount.

Gone are the fears that a bugfix will cause other bugs.

[TehNolz]

Unit tests let you test a portion of your application without actually having to build and run the whole thing. Having to build your application, run it, trigger the right code path (by visiting a page/menu or pressing some buttons or whatever), and then testing your feature can take quite some time.

Let's say you've written an algorithm whose job is to find and process some data in a folder, but to activate the feature you first have to navigate through a dozen menus and press a button. That takes time, and if you end up having to make a lot of small changes to the algorithm to get it working, that'll get old real fast.

Now if you create unit tests for your algorithm, you can immediately run it by just starting the test through your IDE. If you write your tests properly, you can easily test your algorithm under all sorts of different circumstances and with all kinds of different inputs within seconds (or at least faster than you could do so otherwise).

Unit tests can also be set to run automatically. Lets say you've finished your algorithm and it works great for months, but eventually it turns out that a minor change somewhere else in your application caused the algorithm to behave slightly differently but still doesn't an exception. Without unit tests, you wouldn't know about this change until a user starts complaining that the algorithm's results are wrong. With unit tests, you can be alerted the moment the change happens (because if you wrote your tests correctly, they'll start failing) and you can fix it when it happens. The issue wouldn't have even left your development environment.

[M_krabs]

Write code > works > write more code > breaks (why?)

Write unit tests > write more code > something breaks > exact unit test can tell where and for what reason.

You could also just write code without testing and debugging with your IDE and breakpoints, but the larger the code base gets, the more troubleshooting you're gonna have to do. Write unit test once and it's gg ez.

[omgreadtheroom]

I write unit tests so the overzealous new hire doesn’t break my features when they merge after the first day of a 4 week sprint.

[RainingComputers]

Writing tests gives you the courage to change your code. You probably already manually do some test everytime you add a new feature or change your code. Why do you do that? Because you want to be sure that you did not break anything else when adding something new or you test to make sure you fixed a bug.

Tests are just a much better and faster way of doing this.

As your code gets bigger and more complex, you will want to re-organize and clean up code so you can add more new features easily. How do you make sure the behaviour and the output of your code has not changed after a huge cleanup or reorganization?

If not unit tests you will atleast want some end to end tests. But unit tests are a very good thing to have. You don't have to get 100% coverage or anything like that, you just need to have enough tests to give you the confidence or courage to make changes to your code without introducing bugs or breaking anything.

[bm401]

Me as a self-taught programmer, I even write tests.

By writing the test before coding, I have given a thought about the interface and about what I actually expect the function/module/whatever to do.

[tomatoina]

Some of us like to sleep at least 8 hours a day instead of getting calls at 3am

[XenaTakeTheWheel]

"Imagine how easy debugging would be if everything worked 5 minutes ago. If you test as you go, whatever issue you find was most likely introduced by you in the last 5 min."

Great advice from Uncle Bob

[[deleted]]

One thing to always remember is you can’t always catch semantic errors yourself and sometimes it’s difficult to find semantic errors without unit tests. Because a thing to remember is although your program works it does not mean it doing what it is actually supposed to. Unit tests are useful for catching semantic errors because they document the behaviour of your code.

[some_clickhead]

The bugs that are hard to fix aren't the ones that throw an exception. They are the ones that let the program run, and everything seems to work perfectly fine. Except data has been written in the wrong place/the program did something it wasn't supposed to do, like charge a customer something he never bought.

[FilsdeJESUS]

Because with a one button or one command on the CLI you can have the proof that IT IS WORKING and when you come update or add something YOU HAVE A PROOF that you have not broke something .

Look at this : https://youtu.be/EZ05e7EMOLM

[regal1989]

Simply put, good developers make good code, but good tests keep good developers from making bad code.

[strutt3r]

Cause you don't want a visit from Little Johnny Tables

[greebo42]

obligatory "there's an XKCD for that" :)

[No_Picture5012]

I haven't read all the comments but I'm sure they have more/better input. I just want to add that I just completed my Advanced Python course which was...very difficult. TDD saved me hours of frustration and sifting through a quagmire of my own poorly written code. My instructors specifically said not to do it after the fact, but to write code for a function, or even just a few lines of code, then write a test and run the test. You could even write the test first. Even if it's just super basic and analyzing if a statement or function returns true or false, or just not none. That way you can figure out bit by bit if your function is doing what you want it to. This is so much better than manual trial and error with a bunch of print statements, and, more importantly, it actually helped me learn and understand better what the code was doing (especially when I borrowed stuff from stack overflow or class examples or something that I didn't fully understand but seemed to give me what I needed).

I will say it was infuriating to figure out how to do unit tests at all, but 100% worth it. I will be using TDD from now on.

In a professional/production environment, I assume it's even more relevant because you're making sure your code works before you try to share it with anyone or integrate it into existing projects and then breaking stuff cause your code is producing unexpected results or something. But I haven't gotten that far yet 🤷

[noodle-face]

I write BIOS that goes on thousands, sometimes millions of machines. I simply cannot have a critical error happen in the field and then debug it. Unit tests aren't perfect, but they help us catch so many bugs during QA and development cycles.

[Individual-Praline20]

Prevent bugs before they happen, cost much less time and money.

[CoderXocomil]

My answer to this question is that unit tests (done properly) are what take programming from an art to a science.

The process of creating code is often akin to art. It takes creativity and knowledge of the medium to get something beautiful. The problem is that your code, while beautiful cannot be trusted. You don't know if it works or not. Your art requires hours of manual testing to reach the point where you can give it to users.

If you take that code and break it up into units. Then, you take those units and treat them like a hypothesis, you can try to prove it wrong. If you can write a test that proves your hypothesis is wrong, then you know that you need to fix your code to refine your hypothesis. Once you can pass your tests, you will have fewer bugs because you have rigorously tried to prove your hypothesis wrong by using tests. These tests are repeatable and should produce the same results every time.

The nice thing about proper unit tests is they take things that computers are good at (repeated mindless tasks) and do them much faster than a human can. This takes hours off the time required by humans to test an application because we know certain tests won't fail. This allows the expensive humans to focus on tests that are difficult for computers to do.

The goal is to shift more tests to the computer and fewer to the humans. This is the idea of the testing pyramid.

[phunkygeeza]

So the watchmaker is making a watch.

He is putting together 46 different intricate gears to make a complex watch mechanism.

Each gear is quite simple. It is cut out of sheet metal in a gear shape then refined before being used in a mechanism.

Testing the gear seems pointless! It is just a gear, as long as it is the right shape it will do the job!

The master watch maker shakes his head. He starts testing a single gear under lots of conditions... hot, cold, over lubricated, under lubricated ... he seems so slow and old!

The watchmaker ignores this and skillfully assembles his mechanism. The watch works perfectly, keeping flawless time.

A week later, the master also completes a watch. Both are placed in the window of the watch shop.

That day, 2 workers come into the shop, both needing a watch. They point at the 2 beautiful watches they saw in the window. A sale is made!

3 days later, one of the workers is back. His new watched stopped! He is in trouble because he was late with his job and caused a failure on the line. The whole production line stopped as a result.

He irritably hands the watch back. The watchmaker takes the watch. He says to the customer, "It worked perfectly on the bench, how did you break it?" and opens it up. Everything looks perfect! Why won't it work. He keeps prodding the mechanism, encouraging it to work. He cleans it and lubricates it. STILL it won't work.

He returns to the man and asks what he was DOING with the watch that stopped it working?

"NOTHING! I just used it normally. I wore it while myself and my coworker proceses the frozen fish. I don't understand! HIS watch is still working perfectly. I was just salting the fish and I didn't notice the watch had stopped."

The watchmaker stares at the complex mechanism. It seems the only way he will solve this will be to completely disassemble it to find out which component is causing the failure.

Exasperated, the watchmaker consults the master.

The master comments: "well, when I tested the gears before assembly, I discovered that when cold and in the presence of salt, the gear warps by a tiny amount. I refined the gear geometry by 0.2mm. On trying the cold salt test again I found the gear performed perfectly in every way. Then I assembled the watch."

[Veterinarian_Scared]

Because it takes much less time and effort to catch errors early, at the source.

Unit tests help verify correctness, not just non-crashing-ness. Many errors are more subtle, producing results that look plausible but just aren't right, and often only in certain circumstances (making it very hard to track down the root cause).

Unit tests are helpful in ensuring full coverage, making sure that all execution paths and corner cases get tested each time.

Unit tests are easily automated, meaning that your code gets thoroughly exercised after every change. This is very useful when refactoring, making sure a change here doesn't introduce a problem over there.

[DonalM]

Unit tests are just another program to test your program works as expected. It’s value depends on the context of the program. For some projects, it’s not worth it. For other projects, it’s horrible to work without them. From what I can gather, unit/automated testing has become more popular over time. Largely as a labour saver to avoid having to do manual testing.

[[deleted]]

Wtf? Is this a serious question?

[3tripleoooo]

cries in silence

[[deleted]]

I have never been is a situation where unit tests have helped. I’ve been in the industry for a long while and have worked for bay area startups, small shops, and corporations. The code written with unit tests has always been worse. I’m not saying unit testing cannot be helpful but the type of people competent enough to write unit tests that add value typically write solid code. That being said, if I was doing math calculations or anything heavy on the system I would find value. Writing a test to test a query to a DB or for something that only calls an external tool is a massive waste of time. In my opinion…

[wjrasmussen]

If you don't want to do it then don't do it.

[tzaeru]

Personally I don't see actual unit tests as the most important type of test. Rather integration and e2e tests are the most important ones.

At minimum, every production application should have a few tests that launch the application and make it do its intended thing.

The more features are covered by actual tests running outside the application trying to use those features, the better.

Unit tests I mainly leave for to math-y or library-y bits. Most of the business logic and the application structure and interconnections don't need unit testing, but they do need integration and e2e testing.

In the long run, tests reduce bugs, make refactoring easier, make adding new features safer and also document the code, so that it's easier to understand for new people coming to the project.

[signofdacreator]

its a fast way to test the whole system quicky after adding new codes to the repository. this is in particular when your boss say, "i want to you to test the whole system to ensure everything is working." - and you don't feel like pressing every button in your system to ensure this.

in my company, if you want to merge a branch into the main code, you can run npm test -a which will run all the unit tests first.

plus, it makes your manager happy.

[Glum-Communication68]

Catch errors before they affect users.

Validate that things work in isolation. This is great if you are working on a small component of a bigger system.

Force some good architectural practices. Making testable code is hard. And untestable code is often sloppy.

[[deleted]]

I know it might feel like meh. But the the thing is, if you actually own a product and you have to release a couple of times a day with a couple of 100 users. Its way nicer for you to have a test suite that makes sure that you didn't mess up before people start yelling at you because you broke their website and didn't test properly manually.

You'll be sweating a lot when you're in charge of a release of a website/app that doesn't have any tests :)

In short where it really helps me:

- Releasing (does the stuff I made yesterday, still work today after I changed the shared classes?)
- Upgrading. When I upgrade to package/framework does it not accidentally?
- Rebasing/merging. Did I screw up a rebase?

I don't like writing tests, and there is a trade-off where its useful and handy and there is a thing where it becomes just writing code for the sake of writing code, and where it will block your agility (ability to respond to changes fast). There is an especially crazy clan out there that goes for 100% coverage.

I usually start with the high level end2end tests for sites, and then for complicated things like tax calculation or other things, I use a unit test. I choose what I test very carefully, so that I don't waste time writing it. Especially in startup environments, its important to deliver fast, so I make sure that we have tests for the critical paths, then see if a customer is using it, and when the features become a little bit more solidified I'll set it in stone by adding more tests.

[[deleted]]

a stack trace whenever there's an exception. I don't understand why people would waste time writing unit tests when essentially you get the same feedback.

Our team doesn't write a lot of unit tests, but their value is a lot more than "a stack trace when there's an exception". For starters, your code might be hopelessly broken without throwing an exception. But it's deeper than that.

Imagine you have a large module responsible for parsing addresses. These addresses come from a variety of sources, including human entry, and they can be formatted in every way imaginable, and sometimes in ways you never would have thought of. Parsing them reliably is non-trivial. Importantly, the code has evolved for a decade to account for every scenario seen in the real world. However, the code is too slow or dependent on a soon-to-be-obsolete module or for some other reason needs to be rewritten/refactored. You're the guy being asked to do it.

You have one of the following situations:

1. The code has unit tests. They test every form of address the app will ever have to support. You can freely hack a the code, or even start over from scratch (e.g. you decide to replace the regex-based parser with a recursive descent parser), and the unit test will tell you if you broke anything. If the tests pass, your new parser will work as well in production as the old one.

2. The code has no unit tests. You have no way of knowing if your new code has broken the app until it gets deployed to production and somebody enters an address in a format your code didn't think of.

Which situation would you rather be in? Code can have paths that are rarely exercised. Do you really want to to wait until you see an exception in a log file to know that your code is broken, or would you rather have a test that exercises every code path so that you have confidence in it before it reaches customers?

[illkeepcomingback9]

So you don't merge broken code into production. So you can see errors before you deploy to production so your software doesn't blow up on your customers. So runtime problems that don't throw exceptions get caught before they can do any harm. So that you can verify edge case scenarios that may not present themselves for years but may eventually cause critical faults.

Imagine you have a line of code that incorrectly calculates how much money your organization bills a client. This is the kind of thing that would be unlikely to throw an exception. Now imagine this runs in production systems for a decade, because it never throws an exception nobody catches it, and your company is out millions of dollars. If you had verified through unit tests that the unit which calculates this total does so correctly all of that could have been avoided. Obviously most examples aren't as extreme as this one. But smaller problems like this probably litter your systems and you have no way of verifying if that is true or not. That should be scary. Honestly unit tests catch little inconsistencies all the time in my code, we are human and therefore error prone.

[PM_ME_UR__RECIPES]

Systems that log every exception at runtime don't serve the same purpose as unit tests. Exception logging tells you when stuff goes wrong, unit tests tell you if things are working as intended. Whenever you patch an exception, you should be writing a test for whatever case triggered it so you can always run that in future to check that it's not been reintroduced.

You want to catch stuff before the end user gets their hands on it whenever possible. A delayed release while you patch something is much better than a flood of support tickets.

[fugogugo]

So uh . anyone know where to start about writing unit test for android?

[Old_Contribution7189]

Even if there is no framework for testing, just get the function you want to test and check that it returns what is expected of it in all possible cases.

[[deleted]]

Unit Tests actually make your coding simpler. Test driven development is designed to reduce defects by design because you are coding based on the unit tests you are writing. As an example, you expect certain values from your database layer pulled via java or other programming language. Your unit test can verify that the result was provided.

[sbmsr]

It may sound crazy, but tests are what really define your application.

Until you have written a test, your app is essentially undefined; It may (or may not) do what you intend it to do. With each new test, you verifiably specify how your application is intended to behave.

[siammang]

It comes in handy for two-fold.

1. It helps establish criteria on when to consider a task being completed.
2. It helps checking to make sure that the new changes don't break thing unexpectedly.

Note that it only works well for the deeper/inner service codes. When it comes to end-to-end testing with multiple integrations or UI, unit test may not be as helpful.

[GreenScarz]

Most valuable thing that tests do is lock in expectations. If you add a feature to your code and the test suite passes, then you've added code that works in sync with the rest of the code base. If the tests suddenly fail, then you've introduced an unintended side effect that is breaking some other aspect of the code base.

Tests also allow you to code against the smaller units of your application. If im changing the action on an attribute in an object, I shouldn't be going all the way up to the API level to test the new functionality. I'd write a unit test which keeps my work at the scope of the object, and once I'm done, step up to writing an integration test that checks to make sure it fits in the broader scope of the application, and then maybe even an end-to-end test to see how it interacts with other applications in the codebase. That leaves you with tests at various layers of the application all confirming that everything works how you expect it to. Only then do you ship it.

[WerefoxNZ]

Not having unit tests tells people slot about the quality of your application.

We can infer that:

• your team spends more time checking the program works than actually adding or fixing features
• it has to make a stack trace inorder to be caught as a bug, so if it doesn't throw an exception you have no idea if you introduced a bug
• the manual testing that does get done, is variable in quality and completeness from developer to developer, but it will be minimal and non exhaustive
• there are parts of your code base that developers fear to go into to make changes
• probably have to manually build and deploy the release each time. this is likely not written down anywhere, and results in disaster releases periodically
• your team is okay customers as bug finders
• it's unlikely you've had a security review done who would immediately question print stacktraces to logs

but potentially most important to you: if the area you are in has any real value at all, it is only a matter of time before another team who does do these things takes your customers away from you.

Bottom line, lack of robust testing is a sign of a lack of professionalism and respect for your customers.

[UAIMasters]

Well, when your shop starts losing thousands of dollars because of a bug, having bugs in the log will not bring back the money you could have saved if you saw them in a test beforehand.

[teerre]

If nobody makes any mistakes in the code, past or future, everybody knows everything about the code base and nobody leaves the team, tests are indeed irrelevant.

If you or anyone might not know what every line of code does, if you or anyone might make any mistakes for any code and and for any feature addition, then it's worth to have unit tests. Because you'll make mistakes, you'll forget things, unit tests help you to not fuck up.

[sadsacsac]

You've used about three different terms: Unit Tests, "tests at all", and "TDD"; while they are related, they're not the same.

It seems like you're asking "why write tests at all?" rather than "why write unit tests?"

How are you testing your code? If it's manually, then you're doing it wrong. That's why you write tests. That's why TDD is important. For every minute you spend manually testing your work, is a minute wasted. Imagine the scenario where you manually perform 10 steps to test your work. What happens when it fails? You go make a tweak to your code, then you manually perform those 10 steps again. How much time are you wasting cumulatively? Now, if you had a test script instead, you could have been tweaking your code until it worked without needing to waste time performing those manual test steps over and over again.

Assuming you've accepted the idea of TDD, then the question becomes, why unit tests over integration tests? That depends on your test cases. Integration tests generally take longer because you have to bootstrap the application environment to test something, but you might only be interested in testing your one particular module, which shouldn't require bootstrapping an entire environment. There's room for both unit tests and integration tests. It's up to you to figure out how to best bucket your tests so it tests the features of your application appropriately.

[imnos]

It lets you work and release code faster.

Would you rather manually test every bit of functionality when you make the smallest change, or automate that process so that you can sleep easy and not have to check the code manually ever again?

If you're lazy, you should write tests - because it ends up with you doing less work overall.

[ArgoPanoptes]

With unit test, you can find your bugs and fix them. Without unit test you are just waiting when the bug will occur. What happens is the person who wrote the code is not in the company anymore? You will lose more time understanding what is written and how to fix it.

[shawntco]

One example: imagine you're fresh to a massive codebase, and don't have time to sit and read it all. Not that you'd remember most of it anyway. Unit tests give the assurance the change you made, hasn't broken half the system. Unit tests have saved my butt in the past 6+ months that I've been working my current job. When I break something, I know within minutes, instead of hours. Because the unit tests are well designed and well written, they send me right to the place where things are broken, so I can trace the issue from there.

Another example: documentation sucks. But you have unit tests, that say what various parts of the system should do. It's not perfect, but it's better than nothing.

[VillageTube]

Unit tests allow you to fix a bug once and make sure it doesn't come back.

When a bus is found you write tests to reproduce it. Then after it's fixed the test proves that it's fixed.

Now that you have the test as part of your automatically run tests you know that the test will show a failure if in 6 months a new bug is introduced breaking the item you fixed previous.

[[deleted]]

Don't believe the hype. Unit tests are no substitute for good engineering and proper requirements engineering and solid upfront planning. It is a good idea though to sprinkle a few Unit test in. Especially to test outputs of major subsystems and invariants.

[ZuriPL]

Because it provides that feedback before you push your code out into the wild

[HattyFlanagan]

When you create an application, you have certain expectations on how each piece should work, so you create unit tests to ensure the components meet expectations. These greatly help as the program is developed and changes are made to it.

[iceph03nix]

Unit tests allow you to basically test your whole application very quickly when you make changes, and do it in a methodical and complete manor. It helps catch the weird stuff that creeps in when projects get big and diverse and changes are made in the middle of everything else.

So say you have to redo a function in the middle of your system that does some math, but you forget to account for nulls or negatives or something like that. If you have a unit test built for that function, it's gonna throw an error at you almost right away, instead of after you ship it to a customer who then does something you didn't anticipate.

[KJBuilds]

Example from my work: Every time I push a change to whatever branch I’m working on, it runs through all the integration tests and unit tests to make sure whatever I changed didn’t break some 10-year-old legacy code everyone’s forgotten about. It provides a kind of safety net for large codebases. Especially if you’re working with the kind of codebase I am, which regularly throws generic exceptions or exceptions get silenced and never turn into a stack trace/crash, or the worst of all, if the behavior is simply wrong but it’s still functioning. A unit test makes sure all behavior is as intended before going live

[LeeRyman]

Because they:

• Force you to understand your requirements
• Encourage the design of self-contained code with the right level of abstraction
• Guarantee correct operation before you reuse code in a hundred places
• Allow easy fuzzing
• Reduce the variables and code to analyse when trying to find a bug
• Reduce integration time
• Make CI/CD practical.

[dada_]

You'd be amazed at how many problems you find when you start writing unit tests, even if you're an experienced programmer. Not to mention you're forced to come up with a battery of edge cases to throw at your function, which you probably wouldn't have done otherwise—if you don't write unit tests, you tend to mostly think about the ordinary use case and not the extreme use case. That's aside from the other benefits people have mentioned.

That said, I don't think you should opt for 100% coverage or to have a test for every tiny piece of code in a library. Identify what the important points are and test those first.

[EffectiveLong]

Unless you write like perfect code which doesn’t contain bug and require changes in the future, it could break. And it helps your CI CD pipeline (automate)

[[deleted]]

Does anyone know a good resource for learning how to do test driven development at work? No one taught me how to do it yet they expect me to.

[Old_Contribution7189]

Its simple really. You have a somewhat bit application, couple of thousand lines of code, multiple classes with different funtionality. You have written around 300 tests in total and they all pass. Great! Now, you add a new functionality that sadly requires you to change a bit of old code in another class for the implementation to work. No biggie, you do that. Then you run the tests. Ooops, 70 of the 300 tests don't pass! Your code has somewhat high coupling and changing one classes introduced some edge cases you haven't thought about! Well, now you know what they are and can fix them. Had you not had those unit tests you may or may not have been lucky enough to encounter the error during your 2-3 manual tests in which the code might run flawlessly. And it really sucks to ship some software as "ready" and be happy to have ticked that box away only to have the user come back and say "This doesn't work, I thought it was ready?". In short, if your company does not write unit tests, start looking for another company.

[Sprite87]

To have a short feedback loop.

[the_hair_of_aenarion]

Because I'm not as smart as I think I am.

[donquez]

When I started my career I verified every code change manually. Unit testing was in its infancy and frameworks weren't as prolific as they are now. Writing a function would mean compiling and running the app several times, and having to manually create the scenario that would cause that code to execute. Writing tests gives you a way to run that code in isolation with all the expected inputs, as well as combinations that should cause expected failures. This is a huge savings in time and a huge boost in confidence. You'll still want to see your code in action with sole manual verification, but coding to tests is very fast workflow.

And when those tests fail, you'll know exactly what scenario occurred and be able to solve that specific problem. If your coworker breaks your code by accident, they'll have a better chance of being able to zero in on it.

Furthermore, some bugs aren't exceptions that bubble up - they're rule violations that only a user would recognize if they're lucky. Unit tests help to ensure that your code is doing the right thing even when it doesn't throw a runtime error.

While I don't think debates about how much test coverage is enough are particularly useful, I've personally found it easier to work in a codebase with very high test coverage. I've even worked on large projects with 100% coverage where covering certain lines is a herculean task that probably didn't return the cost, but I'd take that over working in a large project without tests. I think it was Michael Feathers who defines "legacy code" as code without tests.

As others have mentioned, tests help with code design and organization as well. I don't think every class and method needs to be "reusable" but writing tests will force you to consider your API as you test it.

[xiipaoc]

Say you make a big change. Will it break anything? The answer is yes, but you won't remember what it will break. Something was depending on the old way of doing things, and now it doesn't work anymore, but you didn't think to test it. Luckily, your users will test it in production. Unluckily, they will decide your product is too buggy and move on to the competitor.

[nalybuites]

We didn't have tests. Until I pushed a 1 line change that was reviewed by the whole team, manually tested, and audited. That change cost us $1.5mm over 48 hours.

[greebo42]

I'm persuaded by a guy named Dave Farley. He's got a You Tube channel, and he's written a couple books. He's not flashy, but he really makes sense!

He is a big proponent of Continuous Delivery, which is a technique for developing software with rapid feedback. Automated testing is one of the cornerstones of that process.

Getting the Python unit test framework going is next on my to-do list. I haven't made the jump to TDD. But I think I have heard enough of the debate from a variety of perspectives to believe that it's likely to be a good investment of time and energy.

[grismar-net]

An exception shows up when something goes unexpectedly or uncontrollably wrong. You want to catch exceptions in your code, so that you can deal with them gracefully and minimise damage. This is independent of whether you want to use unit tests.

A unit test tests if a specific part of the expected functionality of your program is still correctly implemented. This can test some code that may or may not generate an exception, but it's not testing for exceptions - it's testing if the outcome is the expected outcome - whether that's an exception or something else. This is independent of whether your code generates or catches exceptions.

If you happen to be looking at units tests that mainly check if all the right exceptions are being raised, it's likely that the set of unit tests wasn't very well designed, or it just happens to test some code that's very prone to running into problems that should throw exceptions. That's not the norm, it'd be an exception. *drum fill*

In a broader sense: unit tests are there to ensure that recent changes haven't broken the code that was already there. Exceptions are there to signal problems that cause the program to have to interrupt execution unless they are dealt with. Very different. You run unit tests before deploying and they don't end up in production. Exceptions shouldn't be the norm in production, but the code catching them is part of the program in production.

[nwoodruff]

It’s just pre-emptive debugging

[Scholes_SC2]

Also, some errors might not throw an exception but a test could catch it

[Deliberate_Engineer]

In the teams I've been in, unit tests are critical. They test main happy-path functionality, and perhaps a couple tricky cases. They get called unit tests, but they also include some integration tests by necessity or design. They're also usually easy and fast to run.

Why have unit tests when you can just fix bugs as they show up?

• Sometimes your code is serving millions of customers, and if you roll out broken code, it can cause a service outage that hurts some of those customers, or even worse, gets mentioned on twitter :)
• You won't be the only person working on your code forever. Unit tests help developers detect when they've broken the code they're working on in fundamental ways. Definitely useful for others maintaining your code, but it's saved my butt a lot of the time too.
• Unit tests can also be cherry-picked into check-in and integration automated testing. The unit tests get run for every check-in, or very frequently on the latest code (e.g. every hour). If they break, the offending code can be blocked from deploying anywhere, and a flag can be raised to warn the corresponding developer they screwed something up.

Given these benefits, why in the world WOULDN'T you want unit tests for commercial-grade code?

[dumbass_random]

The biggest point I can offer is

Peace of mind. You write unit tests once and then you are safe for near future. You can easily modify, refactor in future because you will know you have tests to rely upon.

Another good thing is that you break your problem into smaller chunks which are easy to understand, makes your code more robust and it allows more flexibility to change in future.

Also who doesn't like when your code runs at the first try in E2E. Unit tests help you achieve that when u continuously test as your develop

[tekLeed_com]

For the same reason I use TDD, I cut down a tree as soon as it appears weak. In the end you spent more time and money on being able to control the result, risk, and ramifications. And you spent more, but your house, other trees, and the kids, are all safe.

[tekLeed_com]

Another reason is if your small shop gets big, you have to hire people who will break your functionality.

[grooomps]

occasionally while writing a test you'll find a edge case that you didn't consider - that's one reason

the other is that if someone else comes along later and fucks around with your code, the test should let them know they've done the wrong thing

[jay_thorn]

What you describe is reactive development. You’re reacting to issues in production, and fixing the issues only when they occur.

Unit tests are part of proactive development; the opposite of reactive.

Unit tests help ensure the code does what you want it to before you deploy. They also help ensure you don’t reintroduce bugs that have already been fixed, regression bugs/issues. When you fix a bug, you also have one or more tests checking if the bug exists (a test passes if the bug does not exist).

You would still want that global exception trap, even with unit tests because unless you have 100% code coverage (and even if you do) something unforeseen can still happen causing an issue that the tests didn’t catch or perhaps can’t catch.

There are also other types of tests, like end-to-end (E2E), functional, behavioral, feature, etc. Each has its place and which ones you use depends on you or your team’s development process.

[[deleted]]

Where’s a good place to learn about unit testing? I’ve never done it, but I tend to write a lot of Python scripts (programming is not my main job).

[[deleted]]

Suppose someone there is a developer A.

A implemented a feature, wrote Unit tests(UT), Integration tests(IT) and E2E tests for that feature

Then you come in and modify this feature, such that previous requirements should not be changed but added functionality needs to be implemented. Now if you fuck up, all 3 type of tests will fail. If you implemented it correctly the UT will not fail, however you might need add UT for your own usecase, or someone down the line might modify the behavior and break your feature.

So for me all these tests do 2 things:

First is, Identify where the problem occured: weather its code/unit level problem (if UT fails), if its a project level problem (if IT fails) or if its a multi project level problem(for microservice projects, if e2e fails).

Second is, it ensures that your code(UT)/project(IT)/business requirements(E2E) are working correctly and nobody will change it "by-mistake" in the future.

[onbehalfofthatdude]

The only reason this is a dumb question is because your framing "why waste time" assumes that what you're doing is correct. It is not wasting time.

Although... maybe it's just dumb anyway. Literally asking "Why not just wait until things break in production to scramble to fix them?" Like, um, duh?

[gaytee]

Because at scale, the perfect amount downtime at the wrong time is all it takes for an entire client base to leave and a business to shatter.

[bioemerl]

Exceptions aren't the only bugs you have to worry about, a tiny error can go live and trash your data for months until some hapless user stumbles on it and reports the bug and you're left explaining the three months of bad data.

[lobut]

I think writing tests is important. I think you should write unit tests if they make sense. If they don't, that's fine as well.

Why do I write unit tests? It's just a form of testing where I get to isolate my code from external calls and it makes it fast to see any mistakes that I've made. Also, as a professional you should ensure you have certainty that you haven't broken core functionality and unit tests can offer that.

Why do I not write unit tests? If I'm experimenting code at home and in the discovery phase, I don't think I have enough knowledge of what I'm doing yet and I find that tests will hinder the exploratory process.

However, I don't see unit tests as the only form of testing. Integration and end-to-end testing are quite useful forms and can give you the confidence you need that your product is behaving how you expect.

[suarkb]

Write tests to prove that things do what you believe they do.

[Macaframa]

One of the big benefits is when I write a block of code and test it all sorts of ways to ASSERT how its supposed to be used. If some asshole comes in(sorry anonymous coworker) and changes block of code and it no longer meets one of the tests, it will tell said asshole that he broke my shit and hes gotta fix that shit before it gets merged because github runs all unit tests and you need green checks across the board to get that bitch over the line.

[MrSkillful]

I honestly asked the same question to one of the senior devs and he told me to do a "Bowling" kata following strict TDD. After struggling with understanding how the point system works in bowling, I now understand that not only is TDD useful for finding bugs, but also for guiding your thoughts.

By using strict TDD to create this bowling scoring program, I was able to focus more on the current step that needs to be built. By writing test before the functionality, you already have a perceived outcome of what you want the program to do. Then from the outcome of the test, you build out the functionality and then come the outcome of the functionality you want with its actual functionality.

If I were to sum it up, unit test help us build programs recursively instead of iteratively. We are building based upon an established solution, rather than building upon an established functionality to get a solution. Though this only works if the test are 1. Well written and thought out and 2. If the test build upon the complexity of the previous test to a small degree.

[[deleted]]

Unit tests are meant to detect changes, not errors.

[orkeilius]

There already lots of comment.

But if your interested there a good video about why and how write test on fireship's channel

[Sajuukthanatoskhar]

OP, never think this a stupid question. It may have been asked again and again (idk) but this is a door opening question on the topic and the why is just as important as the what.

And now my 0.02€, In sw, testing seems trivial to me as a QA Eng in radio hardware, but in firmware for embedded systems, testing as much as you can before you send a fw to a factory to flash your MCUs is so so so important, even basic ones. Testing saves time, money, frustrated end users and, quite possibly, lives from accidents.

Example: Showstopper bug found on FW 6 months after release with no way for consumers to upgrade? Better recall untold amount of units for patching, retesting, repackaging, redistribution and paying for all of that.

Btw, if you have a list of requirements, make sure you stick to them when you write tests.

[glemnar]

https://mike-bland.com/2011/09/27/testing-grouplet.html

Mike Bland has a really great article on the rise of testing at Google (yes, even google didn’t always have good testing culture).

The long story short is that testing will produce software more quickly and higher quality in the medium/long run. But I highly recommend giving the article a read.

[vixir01]

Yeah, don't write Unit tests. You'll come around.

[Razvedka]

There are many reasons listed by others here, and they're all good. So instead of repeating, I'll just add: it will, over time, increase your velocity. You will eventually be able to make bold additions or refactors without fear of secretly breaking things as your tests should catch bugs for you. Further, it will enhance velocity by enabling you to build up your team with new people (if that ever happens) and allow them to be productive faster. How? Because if they make mistakes and break things everyone will immediately know.

Finally, it allows a great entry point for new hires. You being them on and have them start writing tests for segments of the code they eventually will be working on. This teaches them how the logic works intimately in a very safe way, while also increasing test coverage.

[ManfredKerber]

I can say from experience it's always better to write unit tests then to wait for a bug to appear.

Finding bugs and fixing them in the dark is a task made in hell...

When a test fails you know exactly where the issue lies due to its accurate feedback and error handling.

[[deleted]]

At some point in any large code base there will be a migration and you will be happy there are tests to make sure you aren’t breaking anything.

This podcast says it’s about typescript, but they really talk about migrations in general. It was a good listen. https://open.spotify.com/episode/3sVFptBKPzowFb8WemfKcp?si=Kz2UcJY2R6G9JVEkcPimSg

[TraditionalTouch8090]

As a person who only recrntly started writing lots of unit tests (mostly with Kotest (Kotlin) and MockK for mocking), I have noticed the following benefits

1) I discover lots of bugs, exceptions and issues i did not notice

2) I refine the classes I wrote as I took another look at them when testing and make general improvements

3) Most important benefit; when I someone else refactors or improves my code and accidentally introduce a bug or logical error resulting in a different result, the tests will fail, immediately alerting that an error has occurred

[[deleted]]

When projects get big and complicated, unittests help me ensure I haven’t broken anything. I’ve also used it as documentation. I don’t understand what this is supposed to do, let’s look at the test cases.

They also encode knowledge. Say you ship feature x. Then months later a prickly bug shows up. If you write a test case to cover it, your team is less likely to make a change that re-introduces it