Just a question: why do/don’t you write tests?

I catch a LOT of bugs by testing before even running the code itself and looking at the results

pm: ain't nobody got time for that

To ensure future changes don't cause unintended issues with existing processes, unless of course they are also changing.

You can't in good measure know what every use case is and how changing an if() statement will diverge an existing use case to behave incorrectly, so you rely on your tests to ensure things still work the way they should.

If you ever work on a piece of software with many contributors, it reduces bugs without having to manually test everything yourself.

It proves the code is doing what I think it's doing, and catches corner cases before they can become bugs in production, and it does that *every time* I make any kind of modification to the code. All of this for just a bit extra upfront development cost to save the cost of manual testing and (most importantly) lost revenue and reputation from embarrassing situations occuring down the line in production.

I've not met a single, decent, experienced developer who thinks tests are a waste of time. We've all been saved by them at some point.

Not enough time.

I mainly make NPM packages.

1) I write tests for known bugs to ensure they aren't reintroduced later
2) I write tests for functionality because I'd have to write it in the docs anyway
3) I write tests for corner cases for both of the above reasons. Both to document and to enforce behavior that would not necessarily be defined in the concise and newbie-oriented documentation.

To debug bugs.

In my current project I don't because the client changes their mind every other fucking day and I would spend more time changing the tests than actually working.

Time and money. I inherited repos that were maintained by an outside dev agency. One repo had tests but they no longer worked. Agency said they weren’t sure if they could get them working again because that repo didn’t get much activity so the tests weren’t maintained. Tests weren’t maintained because it would mean more time and money.

I also tend to look at the tests when I'm uncertain about the corner case behavior of a library I use, and I encourage my users to do the same

@AlmondSauce It only proves what you programmed it to prove - if you forget about an edge case when you write the code, you're equally likely to forget to test for it. And even if you have the tests, if you rewrite the code to use a different algorithm, it might have different edge cases than those you previously needed to test for. All this for the small cost of having to update multiple tests whenever you make a small change, like adding a new field to a function argument.

Tests give the impression of being more valuable than they are because people are oblivious to type 2 errors. In reality, they only prevent you from repeating known mistakes while forcing you to deal with (potentially annoyingly many) type 1 errors whenever some functionality changes. With that mentality, sooner or later, "write better code" becomes "write better tests", and developers become judged by some skill which consumes more and more of their time without resulting in a proportionally better product.

@hitko If you need to change your tests when functionality changes, they're probably not very good. Changing the parameters of a function across all those tests which don't use the extended functionality when the interface changes doesn't really take much time in most cases with a decent IDE.

@hitko A test suite is an organic thing. You certainly can't think about every corner case, but usually very different implementations share most of their corner cases, so when writing the second implementation you already have tests for most of its quirks, and if you choose to write a third you'll have two sets of tests that are likely to randomly match the corner cases of your code, plus whatever extra you might think of while writing that implementation.

@hitko
"forget about an edge case when you write the code, equally likely to forget to test for it"
It's not about forgetting to deal with an edge case, it's about ensuring the code deals with it properly.

"if you rewrite the code to use a different algorithm, it might have different edge cases"
So... we don't test in case someone happens to rewrite it to use a different algorithm with different edge cases?

"...the cost of having to update multiple tests whenever you make a small change"
You only need to change your tests when you change the public interface, in which case you always need to update other code too. Tests don't add much overhead here.

"Tests [...] only prevent you from repeating known mistakes"
...which is huge. "Known mistakes", in an experienced development team, is a *vast* array of different edge cases, problems, gotchas, etc. that's constantly growing and evolving. Testing whether all that works in one hit is absolutely invaluable.

@lbfalvy If you have createUser function and you add a new field to user object, you need to change all related tests to make sure function accepts it and properly passes it to the ORM. Best case it's not a required field so you can just add a new test, otherwise you need to add it to all existing tests. You also need to update tests for all services which directly call createUser, to make sure they pass in the new field as required.

Another example: a function which calculates the average by summing all values and dividing by N has an edge case where sum causes overflow. An mathematically equal algorithm which calculates the average incrementally has an edge case with precision, but not with overflow. A third approach has better precision, but can potentially break for large count of elements. So each time previous tests will all pass, but you'll leave in a potentially significant bug unless you add new tests on each rewrite.

Tests are extremely useful, especially when debugging Rust is a paid feature in IntelliJ. (I know there's VSCode for that but personally I quite dislike it). This said, sometimes writing tests slows down prototyping so you omit it, then there's this big part of the project with 0 tests that feel like too much of a daunting task to implement so you quietly sweep it under the rug xD

A few integration tests per part of a product are mandatory. If you have too many integration tests per service, you should probably replace a bunch with unit tests.

A few unit tests per class are mandatory. If you have too many unit tests per class, you should probably not be using such a weak ass language.

I write a gazillion tests for PHP and Python

I write few tests for Rust and Haskell

Having a good type system eliminates the need for about 80% of test cases.

I won't bother to get into why we should write tests, the kind of people that don't believe it have got access to every study on it under the sun as well as anecdotal evidence from credible sources like Martin Fowler. If you aren't writing tests by choice then I can't change your mind, and you probably aren't serious about your career as I can't understand why anyone who actually reads tech blogs, tech books, and tries out new technologies on their own would not eventually realise these people all say the same thing. Sure you might be a genius maverick. Probably not.

With that said, if you think not writing tests saves you time you're wrong and should just admit it's because you're lazy. At this point hearing that is just annoying.

@AlmondSauce
"It's not about forgetting to deal with an edge case, it's about ensuring the code deals with it properly."
With well-written code this should be obvious just from looking at code 90% of the time, especially in higher-level languages. The remaining 10% are what needs to be tested.

"So... we don't test in case someone happens to rewrite it to use a different algorithm with different edge cases?"
Why write, maintain, and continuously run tests for a function which won't change once in the next 10 years and is only there because of DRY?

"Tests don't add much overhead here."
Adding a field to a data type only changes the public interface of that data type, but needs to be accounted for in every test which deals with that data type.

"Array of different edge cases, problems, gotchas, etc. that's constantly growing and evolving."
You forgot to mention consuming additional resources on every step of the process, even though most of the code covered by those tests never changes

@hitko
"With well-written code [ensuring the code deals with edge cases] should be obvious just from looking at code 90% of the time."
Come on. You're telling me that you can instantly know that (for example) 90% of date/time edge cases are covered with a quick glance a date/time library?!

"Why write, maintain, and continuously run tests for a function which won't change once in the next 10 years"
Even if this is the case, what maintenance do you need to do on a test that never changes? And how do you know it won't change in the next decade?!

"Adding a field to a data type only changes the public interface of that data type, but needs to be accounted for in every test which deals with that data type."
Nonsense. You only need to account for that in tests that deal with that new field.

"You forgot to mention consuming additional resources on every step of the process"
Unit tests take a *minimal* amount of resources on *one* step of the process, that being the step where you run them.

Gosh… I was just thinking about this when I ended up here. For someone who’s always pro-testing I write woefully little tests. I just realized that because writing tests wasn’t part of our workflow at my job since 2012 (I guess, I saw some old tests somewhere with commits dating so far), writing tests hasn’t sat into my workflow as a natural part of it. It sucks. Everytime I am programming, be it at work or doing side projects, I go in thinking TDD/BDD, but then I just…. forget to write the tests.

Well, at least I have submitted a PR to start including a unit testing toolset into our workflow and with it a bunch of tests to kickstart it. It’s just that it’s been waiting for review for quite a while already. Funny, how everyone agrees tests would’ve likely saved us from bug X in prod, but no one’s bothering to get testy.

But yeah, I forget tests way too often.

@jAsE-cAsE: "So there... Fuxk unit tests"

Also @jAsE-cAsE: ""No one will hire me 😭"

😂

I do because it helps me create a better design, know I’ve got the requirements covered, and test over and over much faster than ok can compile+run+debug.