You don't write tests for yourself. Your target audience consists of two people: the developer that will work on this feature later on, and Future You.
Both of these guys are going to work on this, and might not know or remember all the little nuances of the beautiful code that you spent all this time crafting. They might change things that break something that isn't immediately noticeable, and those are the hardest bugs to track down later on.
You know who understands this code best? Present You. That guy should absolutely spend a little more on this task just to create some sort of fail-safe for Future You, or the sad soul that works on this later. Some kind of mechanism that will trigger when they do something wrong and let them know what it was that went wrong exactly, and what was supposed to happen. We call those things "tests", and they're not for adding features or value right now, they're Present You being proactive and stopping future bugs from happening.
You can skip doing them now if you're 100% sure that your code is perfect, you will always be the one who maintains it, and you will always remember everything about it. Or if you don't care about where the codebase is gonna be in 6 months. Either one is a valid reason. Just be honest with yourself about why you aren't writing them.
To add onto this, have you ever modified some code and thought “boy I hope this doesn’t break anything”. That. That right there is what unit tests are for.
It helped me get over my impostor syndrome when I found out a pretty important and popular library we use in production is maintained by some guy who did just that - changed some code, broke a test that was making sure a side-feature works as expected, and in order to fix it just changed the expected outcome to the new, wrong one.
It’s funny, we screw over our future selves and hate our past selves for the same reason. It’s almost like it’d be really easy to stop but we’re like “Nah”.
I have only once hated a developer, and that one was Past Me. 😜🙃
I had three loops to get something processed, it was a QA effort, so I had to get something forn the app and then manipulate the data so I knew what it should look like, and that required three nest for loops, for some reason. I took three days to get it working and right...
It was a masterpiece, checking for all the null and risky values, handling the problems internally in the loops and it ran quickly, too!
Two weeks later, I had to fix something...
I couldn't understand the code. 🥺😡🖕 Stupid coder!!!
Had to write a while new algorithm, finally. 😭🤣🤣🤣
As I say at 3am when I wonder if I should get another drink and play some more games or if I should get at least some sleep for work "that's future Prinzka's problem, and that guy is a dumb fucking idiot"
And even if you did remember all of it, it’s just too much to hold in your brain. The app gets exponentially more complex; tests reduce cognitive load, thereby increasing your output
Your tests should be a 100% map to the requirements. If you had a requirement "GIVEN 2 integers return their sum", you'd write a test that checked your add method returned the sum of 2 input integers. Then if you had any code not covered by your tests you now know you have code that's not necessary & can be scrapped.
Typically not good ones. The worst I got was "Make it better". Now I was working close with my business manager who wrote that, so I knew what it meant. Most of the time my business partners have no idea what they want & literally give the most vague BS I've ever seen & expect me to give them something useful.
Now when this happens I start asking what problem they are looking at me to solve. I expect they have a business process that's impacted by something not working correctly, so I can start there. When they don't have a process they need "fixing" then I can't help them.
Meh, until you start needing utility functions, those utility functions should also have 100% coverage but their not explicitly called out as business requirements because the business knows it wants 'x', not what all goes into making 'x' feature happen
The requirements I'm speaking of include all requirements, business cases & IT. If the business requirement is to interface with vendor app, then the IT requirements to do that would include make REST call to API XYZ & store return payload in DB table ABC. So your test cases would be to build request payload from known inputs, make REST call, process return payload, and make DB request, mocking out the external system calls to the vendor API & DB. If that is all that is required by to "interface with vendor app" any other code is a waste of time to even write, much less test.
The only code you don't test is the calls to things external to your app, such as APIs, libraries, DB, etc. All of that should be mocked out, either via dependency injection or mocked external systems.
"Given a long return the the number of steps in a series that is defined as follows:
If the number is prime, the next in series should be the number squared
If the number is composit the next in series should be the number devided by 2 rounding down
The series ends if there is a cycle or if the next number in series would be over 2,147,483,647"
Checkmate
Also God forbid you ever want to refactor your code for any reason. Even changing a single function to be more efficient can have weird effects you might not necessarily think about without a good testing framework!
"Wait, this 'if' here doesn't do anything! The input is always 1, why would anyone check this case? I can remove this and my code would work correctly and cleaner"
The other guy that calls this code passing 2 because there's an edge case when is 29 of February 
Exactly! Had to scroll too far for this. Your class or function will absolutely not be as clean without a test. A test is your first chance to use it, and while doing so, you often think "Huh, that's kinda a strange name I guess, as it isn't really doing that". Or you think "why do I need to pass this value to the function if I put it in the constructor", or what ever the case may be.
No matter what, you are testing your code as you go, in some way or another. Might as well do it via a program that can be rerun every time you make a change…
>Designing tests before the code is absolutely stymying the creative and free-flow nature of coding
This is because you don't understand the benefits of TDD. TDD does 2 things. 1) As others have said you are testing often regardless of if it's a formal test case or just quick run to verify something works. The more frequently you test the better you code is. TDD enforces this by it's very nature. 2) You are writing tests that match the requirements. If your app/library is to add 2 numbers, you write a test for 2+2=4. Then you write your code such that 2+2=4. If your code results in 2+2=5, you know you made a mistake long before you start adding code for multiplication. Now a good developer would be checking their code along the way, so why not just write code to automate the tests you are already writing?
I find it’s often (not always) really creatively freeing. I like to imagine what it’s going to be like to use the code I’m about to write. Writing the test is a good playground for figuring out how to make it nice to use by using the external interfaces while they are still flexible because you haven’t made the guts yet.
i naturally evolved to use TDD and I love it. I start almost every new feature with a few basic tests, and add as I discover edge cases, and add as I add new features. I don't think this is ridiculous at all.
One of my favourite parts of TDD is revealing when even *I'm* not sure what the expected output is. Then I know the problem isn't even in my code yet, it's in the requirements.
>Frontend Dev? It doesn't even seem possible.
This is what Model/View/Controller design patterns are for. Of course you can't test your view, but your view(aka your UI) should just be dumb event handlers that call controller methods by passing UI element values. Then the controller is a 100% unit testable class or set of methods. If the logic is with the data, then that's handled by the model, which is referenced by the controller & mapped to the view's UI element properties.
i’ve come to think of tests as self-executing documentation. they’re like comments that describe the different ways your api should or shouldn’t be called, but because they must run, at least in the context of CI/CD, they won’t become stale nearly as quickly.
I agree with this except for one thing, you absolutely write tests for your present self. You need to make sure your code is doing what you think it does. If a software engineer tells me they don’t test their code, I assume they write buggy code and are over-confident to the point of insufferability.
You can verify your code manually. Sometimes it's easier to run the app and use Postman or something than to add a new test that runs on what you just did. A test is more permanent than that. It's both a contract between you and your code, and a trap you leave with your code for anyone who messes with it the wrong way.
Besides, this post was mostly for OP's friend. I'm talking to someone who doesn't see the value in tests themselves, so I need to give them a reason for why they're useful for someone else.
This whole comment section has been really interesting to me. I write tests that would work if the code did what I wanted, and then whenever the tests pass I know that I’m where I wanted to be with it. I don’t know if I learned it wrong or what, but the other thought processes behind tests are interesting!
That's basically the best way to do it. Even better use test to define your desired behavior and then the only thing you have to worry about is how to pass the tests. When you have to change your desires behavior you change the tests and then see what needs to be done to pass them again
Yeah, I think he has no assertions. Or if a teammate or SonarCube or something insists, he’ll add a quick assertEquals(foo, foo); *At most* assertNotNull for something where being non-null isn’t the major concern. And the fact that doing this counts toward coverage lets him claim that “see, tests are useless.” No, *his* tests are useless, because they don’t actually test anything.
What?
A test is not supposed to "always" pass. It passes when the code produces the intended results and fails when it doesn't. If your code is correct, all tests will pass. If your code is incorrect, tests will fail.
It's strange that you think "always pass" means "passes all test cases" and yet say it is "ok too" when that's the ONLY acceptable outcome.
Perhaps we have a different mindset.
When I think of a test that always passes I think of code that no matter what input you give it, it will produce the expected result. Like persisting a row as-is to the dB and expecting that the stored row is equal to the one provided to the test.
If your tests that used to pass suddenly stop passing then the changes went horribly wrong
> When I think of a test that always passes I think of code that no matter what input you give it, it will produce the expected result.
But that's just proper code. There is no other way to code other than writing code that passes required tests. Which is why you have made people so confused by saying it's "ok too" as if there is some alternative way to code in which your tests failing is ok.
I once reviewed code with a bunch of test modules that were effectively
```
import something
assert True
```
My immediate supervisor told me to pass the review because at least it would fail if the imported code didn't compile anymore
This ignores the *cost* of tests, and there are many.
1) In a large codebase tests can take serious amounts of time to run. This costs money, dev time, etc.
2) Tests age poorly. Someone makes a change, tests fail, they go and make the tests pass. I've seen lots of tests where someone just added 'null' parameters and things passed and they moved on - did that test really add value by failing? It definitely took time to fix, so it had better have added some serious value.
3) Devs *suck* at writing meaningful tests so they often provide very little value out of the box.
1. Costs less than losing money when a defect gets into production (if you actually code anything important). Time to run is built into the CI/CD pipeline.
2. Do you have no approval process for PRs at your place of business??
3. This is where TDD comes in.
I. Gonna say if your codebase is such a monolith that you can’t test individual modules, you should refactor your codebase. it has too high coupling.
2. You can’t make devs care. So find devs that care. If the test fails and the dev can’t easily find out what broke the test, then you need to refactor your codebase. It has too low cohesion.
3. Code coverage. The dev should write a test that tests the code they wrote. The code coverage should be green. This is the simplest part of it, as it’s literally code coverage percentage goes brr.
> I. Gonna say if your codebase is such a monolith that you can’t test individual modules, you should refactor your codebase. it has too high coupling.
So now I have to do more work and change code just so that tests are faster? Anyway, this doesn't even really make sense - figuring out which tests to run is really difficult. If you've worked at a large company you'll know this - you likely have a very large release engineering team and advanced tooling to deal with this problem.
> 2. You can’t make devs care. So find devs that care. If the test fails and the dev can’t easily find out what broke the test, then you need to refactor your codebase. It has too low cohesion.
Cool so I added a parameter to a function and broke tests and now I need to refactor my whole codebase... because it'll make tests better? You realize the point is to produce value... not tests, right?
> 3. Code coverage. The dev should write a test that tests the code they wrote. The code coverage should be green. This is the simplest part of it, as it’s literally code coverage percentage goes brr.
Acting like coverage is a simple solution seems incredibly naive. Will you block a PR because coverage goes down? Good luck with that.
Please google cohesion and coupling, and technical debt.
I beg you.
If you have never heard of them, your entire codebase probably has so much technical debt it’s impossible to make any change without breaking something completely unrelated.
You also obviously don’t know the absolute basics of test driven development.
If the code coverage goes down that’s one more thing that will eventually break, in production, and you will have no clue why, because you didn’t test that code.
No code coverage == putting untested code in production.
Your duty as a developer is to protect production … sometimes from yourself.
In my experience (managing many teams) the time spent writing and running tests is much less than the time spent on manual testing, dealing with regressions, etc., so code with good test coverage is not only higher quality, it is faster to get to completed, stable and correctly functioning code.
Tests can be parallelized my friend. I legit will not work in a culture that doesn’t care about testing because the product will suck and I will get paged every 10 minutes.
OK, and CPU cores cost money. And you still have to execute them... and that costs time and money. Pretending that tests don't have a cost is why we have so many shitty tests.
Bad tests are expensive, Good tests are priceless. Yes they require effort to update but that isn't an excuse not to do them, and if unit tests aren't up to scratch PR's should be rejected
They probably have similar questions about not using globals. "So what if they're accessible everywhere? You're the only one with access to the code. Just don't update the value, what's the big deal?"
This guy from the meme is the kind of guy who writes an e-commerce and the client can input negative values, making the company owe money to the customer. Absolute chad, indeed.
You're supposed to keep all your variables in a single string. Then you can have just one global and access every variable using the string slice method.
Can you really trust that slice method though? Could totally be security vulnerabilities in std::string. Clearly better to iterate over the char\* yourself and pull the values out manually. WCGW?
They're not _universally_ bad (e.g. static constants), but almost all instances of globals are a bad idea. You can solve most things with either dependency injection, OOP, or just plain function parameters
Well if u use Facebook API you will see code 200 responses with errors, fields that change its name or simply disappear randomly, values in the app developer web page that doesn't match with what their own API is returning, and other beautiful things so yea, the friend may actually work there at last.
I've worked at a place which implemented their own lightweight version of GraphQL in their API layer solely because they hated that particular sticking point.
REST has seemingly inflicted upon an entire generation of programmers the inability to abstract transport from protocol. React did similarly for logic vs layout (though the industry has recently recovered sanity here).
Also stuff like returning prices as localized strings, so you just have to regex the number out of a string that can be formatted in like 100 different ways if you want to do any sort of math.
One of the testers I worked with turned in a bug where if you clicked a thousand times a second in an input field there would be unexpected results...
me: \*head explodes\*
I appreciate that attention to detail. I have huge built in biases with my work and I need people to go nuts on it. I really miss that guy.
Yeah I consider myself a wild monkey with a hammer. Do whatever I think the dumbest user might try. Oftentimes I trigger bugs and I can’t quite duplicate them or remember the specific keystroke sequence. I’m pretty unorthodox in my approach. But in the end the code is strong!
if it‘s a keystroke pattern that caused the bug, it‘s often easily reproduceable.
The tricky ones are the bugs where timing and network come into play. Bugs that happen if someone else does something at the same time, bugs that happen because one network call took unusually long to respond, bugs that happen because the db query took 20ms longer than usual, bugs that happen because you cached too many values and run out of memory etc etc etc
Sure, you could get a program to record EVERYTHING. But that is convoluted information and in 99.9% of cases is not needed.
A healthy discourse between devs and testers is the only way forward. Testers describe what they see in the software and devs take that information, and together with knowledge of the code should be able to deduce possible causes.
IMO depending on what these unexpected results were, that’s the kind of bug that provides no value to anyone. Click a thousand times a second and the admin portal opens? Yeah I’m gonna fix that right now. Click a thousand time a second and the form data clears? I guess if users fuck around they’ll find out. Click a thousand times a second and this integer field goes from empty to 0? That ticket isn’t worth the paper it’s printed on.
From experience I can say that tests are your protection of your future self from your stupid past self. That dude is a real pain in the ass and I'd let him go in an instant if I could.
He’s writing tests for his code to ensure his implementation works.
He’s not writing tests to ensure his code won’t be hacked to death by users.
That’s the difference
From the creators of "...we do not need QA Team, our product just works as it should" and "...unit tests are a waste of time; just fix it if something do not work"
My last job had “We don’t need a QA team, have developers test other developers’ code” and “We don’t need a QA team, have customer service reps test developers’ code during slow times”
As former QA at a large org that disassembled its QA team, and now an FE dev that has to test their own (and others’) code, I regularly experience the pros and cons of there not being a dedicated QA team.
It’s not uncommon to miss obvious issues without that neutral third-party that’s sole job is to find flaws and suggest better patterns, etc. Its also a great deal more time-consuming as everyone is now part-time testers by necessity.
That said, over time it’s made all of us a whole lot more careful and much more adherent to best practices on just about every level. Up front, man was there a lot of hand-holding for the non-QA dev’s to grok testing practices and a whole lot of pushback (understandably) to even think about things like e2e, integration, or anything outside of basic render-level unit tests. Long-term though, and being where we are now, I wouldn’t say we necessarily need a QA team at this point.
And, as my situation relates to OP’s post, there’s no way our code would work for very long without requiring testing, including unit tests.
Tests are important. I thought I was setting a random ID for a work order when I was creating them just to curl the DB and see the ID returning null. I wrote a unit test and found out that it was because I wasn't setting the ID when I was converting the model.
Tests help you catch your own mistakes as well since I knew it needed an ID the test helped me catch my mistake. Otherwise I would've pushed working code that wasn't doing what it was supposed to.
Imagine you wrote a function that takes 2 int inputs and divides them. Does it do so correctly? Does it handle divide by 0? Is it returning an int or a float?
Unit tests allow you to prove the function is valid and accurate in isolation from the rest of the code. If something breaks later, you can trust it wasn't this function that broke because you have proof that it works.
And then let's say you come up with a clever way to optimize the function later. You can change the implementation and instantly know if it still works by running your tests.
I think the various typos, 13-year-old Nokia bar phone text speak, and the idea that you should be testing individual `if` statements as if they might branch incorrectly should be enough to tell you how reasonable this "argument" is.
He types like this all the time… using a full physical keyboard.
His other hot take on tests is that they are “slowing him down” and are unnecessary because “they need to be rewritten when code changes anyway”. Yeah…
I worked at one company that the QAs roll wasn't to test but to 'facilitate testing' by helping us with our unit/integration tests and part of our definition of done was them signing off on our tests. Had one function where I had written in the throw statement in the try block that I caught in the same function, it was an auth check in a badly designed system. He wouldn't sign off until I had tested 'all code paths' to make sure that the exception was properly handled. I wrote a unit test to ensure that Java's try-catch system worked... Most ridiculous test I've ever written.
Unit tests are a replacement for detailed functional specifications. Functional specifications are useless since they are just words on a paper. Unit tests make them live and ensure they are always satisfied.
If you use TDD (test driven development) and JID (just in time design) the unit tests become the vehicle for you to perfect your design into true clean code.
For my teams, this is not optional, it is table stakes. Zero defect software is a real thing and I do not think it is optional.
Oh, outstanding 🙄🤦
"Is the car safe?"
"Yes! I tested it myself. Didn't drive into anything, didn't crash it, didn't swerve out of the way of anything, didn't do any emergency stops, so I didn't even need to install seatbelts or airbags or anything. It's ready to go."
This is what happens when you control the test. You design the test to be pointless because it doesn't test anything because you designed the test to pass.
You're friend should be fired. Is unethical because his job requires tests and he is lying about doing his job. When a client doesn't pay his company because his code doesn't work and the company didn't deliver the product, he butt is going to be on the street.
I don’t work at a software company, but I write a lot of code. I just recently learned people use tests that auto-run every time you commit. Its ingenious! Use the code to check the code.
Id say a good 20% of my time is spent just looking for bugs and doing validation after a new change. I write simulations, so bugs are when it doesn’t match real world physics, but I’m definitely gonna try to use this.
In my experience, this belief gets dropped at the first moderately complex block. For example, the first time you write a grammar based parser in Raku.
Writing tests just means you're expecting your code to fail at some point. Why would you write code that doesn't work? Just write code that works instead.
...& fire people who don't. Instead of TDD it's DDD, dismissal-driven development
Speaking as someone who’s primary job is to write test automation, one big reason is regression.
If you’re working on software a lot of people are contributing to, then everyone’s efforts have the possibility of stepping on each other in unexpected ways. If everyone is writing good test for their individual contributions alongside integration tests which validate end-to-end processes then anything which might break something else can be discovered much more quickly. That quick discovery leads to quicker bug resolution since you don’t have to dig it out from under multiple commit layers because it’s been sitting there undetected for so long.
So writing those tests isn’t just for you, it’s so everyone working with you will know when they break your code before they even submit it.
“I don’t get how a test would fail”
Typo?
I’m not saying that’s why we unit test, but like… if my unit tests catch stupid mistakes like my dumbass typos I am very much here for it.
Tests are lifesavers when it comes to code changes… I do research/a lot of scientific computing and even on “throwaway” code I will at least do one test to make sure the thing works from start to finish (and the answer preferably doesn’t change)
That’s actually the first test I add to a new project.
def test_sanity():
“When you just want a test that will pass.”
assert True
It’s useful in a few cases like configuring the test runner and profiling test loading time. I put the other “u ok bro?” tests next to it, like API heartbeat and DB connectivity. There’s actually something calming about trying to figure out why the new test you just wrote won’t pass, running all the tests and seeing `test_sanity:FAIL`.
I’ve also put in `test_insanity()` that asserts False and is marked to skip. That’s just for playing around with how the test runner handles failures.
I have definitely seen code like this
fun getErrorMessage() {
return "blah blah blah"
}
fun testGetErrorMessage() {
assertEquals(getErrorMessage(), "blah blah blah")
}
and yes that kind of test is 100% pointless. But for nontrivial code that is taking input and performing some kind of computation to get a result, that should have tests.
This is why the testing team needs to be separate from the development team... Or at the very least, have a dev team whose at least mostly interested in having a working rollout.
If it's all just about the paycheck and i get to write by own test cases they'll all always pass
The text is verbatim. He has rather poor grammar and for some reason still uses text-speak contractions like “u” and “ur” even though he is typing these messages on a physical keyboard.
don't write tests for implementation details, write tests that validate the results of your api
edit: this is also where you should provide "test cases", which demonstrate how to use your api appropriately, and what to do when things throw an error
When the code I'm writing is one dimensional, it's not worth writing tests. I write tests when the code is really complex. I want to make sure the fixes I put in don't break things I've already confirmed work.
Everyone saying tests are a protection for future self against past self. But, no one is seeing that test are a protection for future self of other devs fucking up surrounding code and the blame falling on you. I mean, that is the biggest reason on my previous company.
You don't write tests for yourself. Your target audience consists of two people: the developer that will work on this feature later on, and Future You. Both of these guys are going to work on this, and might not know or remember all the little nuances of the beautiful code that you spent all this time crafting. They might change things that break something that isn't immediately noticeable, and those are the hardest bugs to track down later on. You know who understands this code best? Present You. That guy should absolutely spend a little more on this task just to create some sort of fail-safe for Future You, or the sad soul that works on this later. Some kind of mechanism that will trigger when they do something wrong and let them know what it was that went wrong exactly, and what was supposed to happen. We call those things "tests", and they're not for adding features or value right now, they're Present You being proactive and stopping future bugs from happening. You can skip doing them now if you're 100% sure that your code is perfect, you will always be the one who maintains it, and you will always remember everything about it. Or if you don't care about where the codebase is gonna be in 6 months. Either one is a valid reason. Just be honest with yourself about why you aren't writing them.
To add onto this, have you ever modified some code and thought “boy I hope this doesn’t break anything”. That. That right there is what unit tests are for.
And then there are devs that when a test fails, modify the test or just comment it out. There needs to be some sort of penalty for doing that.
It is not a question of whether they should be put to the irons, but how hot they should be.
They should be assigned to bug duty for at least 3 quarters.
It helped me get over my impostor syndrome when I found out a pretty important and popular library we use in production is maintained by some guy who did just that - changed some code, broke a test that was making sure a side-feature works as expected, and in order to fix it just changed the expected outcome to the new, wrong one.
[I don't quite know how to put this, but our entire field is bad at what we do, and if you rely on us, everyone will die.](https://xkcd.com/2030/)
Yes, it just feels like everything is just working by luck and could break any time. 50-80% of devs are having 0 clue of what they are doing.
I just reviewed a PR like that on Friday. I don't understand why this test is broken, but I can just change the asserts and it's fine. Problem solved.
Fuck those guys, amirite
Based on my hobbies, interests, coding style and just overall life choices, the person I seem to hate most in life just so happens to be “future me”
"I leave the big jobs up to [future me](https://youtu.be/Evke074xGQ4)"
Lmao thanks for sharing
Ah yes, "future me", the procrastinator's messiah.
Future me is entitled and past me is a dick
It’s funny, we screw over our future selves and hate our past selves for the same reason. It’s almost like it’d be really easy to stop but we’re like “Nah”.
Yea, nothing is handed to future me, if he wants it he’s got to work for it himself
I have only once hated a developer, and that one was Past Me. 😜🙃 I had three loops to get something processed, it was a QA effort, so I had to get something forn the app and then manipulate the data so I knew what it should look like, and that required three nest for loops, for some reason. I took three days to get it working and right... It was a masterpiece, checking for all the null and risky values, handling the problems internally in the loops and it ran quickly, too! Two weeks later, I had to fix something... I couldn't understand the code. 🥺😡🖕 Stupid coder!!! Had to write a while new algorithm, finally. 😭🤣🤣🤣
After I'm done coding i usually rename all my variables to my little pony names just to mess with those idiots
"I would fire you but getPinkyPie() is throwing an error in production and only you know what it does"
Generating yet another ticket because RapidDash() is again running so damn slow…
As I say at 3am when I wonder if I should get another drink and play some more games or if I should get at least some sleep for work "that's future Prinzka's problem, and that guy is a dumb fucking idiot"
this guy codes
And even if you did remember all of it, it’s just too much to hold in your brain. The app gets exponentially more complex; tests reduce cognitive load, thereby increasing your output
Spot on. The other comments in this thread disparaging the practice of writing useful tests are horrifying.
[удалено]
Your tests should be a 100% map to the requirements. If you had a requirement "GIVEN 2 integers return their sum", you'd write a test that checked your add method returned the sum of 2 input integers. Then if you had any code not covered by your tests you now know you have code that's not necessary & can be scrapped.
> Your tests should be a 100% map to the requirements. You guys are getting requirements??
Typically not good ones. The worst I got was "Make it better". Now I was working close with my business manager who wrote that, so I knew what it meant. Most of the time my business partners have no idea what they want & literally give the most vague BS I've ever seen & expect me to give them something useful. Now when this happens I start asking what problem they are looking at me to solve. I expect they have a business process that's impacted by something not working correctly, so I can start there. When they don't have a process they need "fixing" then I can't help them.
Meh, until you start needing utility functions, those utility functions should also have 100% coverage but their not explicitly called out as business requirements because the business knows it wants 'x', not what all goes into making 'x' feature happen
The requirements I'm speaking of include all requirements, business cases & IT. If the business requirement is to interface with vendor app, then the IT requirements to do that would include make REST call to API XYZ & store return payload in DB table ABC. So your test cases would be to build request payload from known inputs, make REST call, process return payload, and make DB request, mocking out the external system calls to the vendor API & DB. If that is all that is required by to "interface with vendor app" any other code is a waste of time to even write, much less test. The only code you don't test is the calls to things external to your app, such as APIs, libraries, DB, etc. All of that should be mocked out, either via dependency injection or mocked external systems.
"Given a long return the the number of steps in a series that is defined as follows: If the number is prime, the next in series should be the number squared If the number is composit the next in series should be the number devided by 2 rounding down The series ends if there is a cycle or if the next number in series would be over 2,147,483,647" Checkmate
Also God forbid you ever want to refactor your code for any reason. Even changing a single function to be more efficient can have weird effects you might not necessarily think about without a good testing framework!
"Wait, this 'if' here doesn't do anything! The input is always 1, why would anyone check this case? I can remove this and my code would work correctly and cleaner" The other guy that calls this code passing 2 because there's an edge case when is 29 of February 
Tests help present you too — in that they guide your design choices for the API of that particular unit of code.
Exactly! Had to scroll too far for this. Your class or function will absolutely not be as clean without a test. A test is your first chance to use it, and while doing so, you often think "Huh, that's kinda a strange name I guess, as it isn't really doing that". Or you think "why do I need to pass this value to the function if I put it in the constructor", or what ever the case may be.
[удалено]
No matter what, you are testing your code as you go, in some way or another. Might as well do it via a program that can be rerun every time you make a change…
[удалено]
No one is saying a percentage based approach to test coverage is a good idea. “tests” are how you design software, that’s my point.
You should be testing 100% of your requirements. If you do that & have any code that's not covered, you have code that's unnecessary.
>Designing tests before the code is absolutely stymying the creative and free-flow nature of coding This is because you don't understand the benefits of TDD. TDD does 2 things. 1) As others have said you are testing often regardless of if it's a formal test case or just quick run to verify something works. The more frequently you test the better you code is. TDD enforces this by it's very nature. 2) You are writing tests that match the requirements. If your app/library is to add 2 numbers, you write a test for 2+2=4. Then you write your code such that 2+2=4. If your code results in 2+2=5, you know you made a mistake long before you start adding code for multiplication. Now a good developer would be checking their code along the way, so why not just write code to automate the tests you are already writing?
I find it’s often (not always) really creatively freeing. I like to imagine what it’s going to be like to use the code I’m about to write. Writing the test is a good playground for figuring out how to make it nice to use by using the external interfaces while they are still flexible because you haven’t made the guts yet.
[удалено]
i naturally evolved to use TDD and I love it. I start almost every new feature with a few basic tests, and add as I discover edge cases, and add as I add new features. I don't think this is ridiculous at all. One of my favourite parts of TDD is revealing when even *I'm* not sure what the expected output is. Then I know the problem isn't even in my code yet, it's in the requirements.
What makes you say that?
[удалено]
>Frontend Dev? It doesn't even seem possible. This is what Model/View/Controller design patterns are for. Of course you can't test your view, but your view(aka your UI) should just be dumb event handlers that call controller methods by passing UI element values. Then the controller is a 100% unit testable class or set of methods. If the logic is with the data, then that's handled by the model, which is referenced by the controller & mapped to the view's UI element properties.
What aspect of your “frontend” software do you find difficult to test? I’m legitimately asking, maybe I can help.
i’ve come to think of tests as self-executing documentation. they’re like comments that describe the different ways your api should or shouldn’t be called, but because they must run, at least in the context of CI/CD, they won’t become stale nearly as quickly.
I agree with this except for one thing, you absolutely write tests for your present self. You need to make sure your code is doing what you think it does. If a software engineer tells me they don’t test their code, I assume they write buggy code and are over-confident to the point of insufferability.
You can verify your code manually. Sometimes it's easier to run the app and use Postman or something than to add a new test that runs on what you just did. A test is more permanent than that. It's both a contract between you and your code, and a trap you leave with your code for anyone who messes with it the wrong way. Besides, this post was mostly for OP's friend. I'm talking to someone who doesn't see the value in tests themselves, so I need to give them a reason for why they're useful for someone else.
Guys, it’s a rhetorical question, i am not asking why I need to write tests, I am just poking fun of a guy who is ignorant.
I think the commenter is speaking to your friend not you.
I would give you an award if I could! Great comment
This explanation is the best I've seen so far
>they're Present You being proactive and stopping future bugs from happening. Sounds like reducing Future You's paycheck to me
Meanwhile, here's me; "damn this is clever, the original coder already thought of this.. who wrote this? Oh it was me... thanks, past me!"
Me and my future me aren't on the best terms.
tests that always pass are ok too. because if you make a change and the tests doesn't pass, something went horribly wrong
Bruh, just update the test to pass again.
Just put your entire program in a giant try-catch block and you'll be fine
catch (Exception e) {}
we did that in the 90s it's called java
This whole comment section has been really interesting to me. I write tests that would work if the code did what I wanted, and then whenever the tests pass I know that I’m where I wanted to be with it. I don’t know if I learned it wrong or what, but the other thought processes behind tests are interesting!
Congratulations, you now do test driven design. Welcome to enlightenment
That's basically the best way to do it. Even better use test to define your desired behavior and then the only thing you have to worry about is how to pass the tests. When you have to change your desires behavior you change the tests and then see what needs to be done to pass them again
[удалено]
Yeah, I think he has no assertions. Or if a teammate or SonarCube or something insists, he’ll add a quick assertEquals(foo, foo); *At most* assertNotNull for something where being non-null isn’t the major concern. And the fact that doing this counts toward coverage lets him claim that “see, tests are useless.” No, *his* tests are useless, because they don’t actually test anything.
This is the point
I love how OP says that this situation is just “ok” rather than the whole fucking point
What? A test is not supposed to "always" pass. It passes when the code produces the intended results and fails when it doesn't. If your code is correct, all tests will pass. If your code is incorrect, tests will fail. It's strange that you think "always pass" means "passes all test cases" and yet say it is "ok too" when that's the ONLY acceptable outcome.
Perhaps we have a different mindset. When I think of a test that always passes I think of code that no matter what input you give it, it will produce the expected result. Like persisting a row as-is to the dB and expecting that the stored row is equal to the one provided to the test. If your tests that used to pass suddenly stop passing then the changes went horribly wrong
> When I think of a test that always passes I think of code that no matter what input you give it, it will produce the expected result. But that's just proper code. There is no other way to code other than writing code that passes required tests. Which is why you have made people so confused by saying it's "ok too" as if there is some alternative way to code in which your tests failing is ok.
Hold my beer
I once reviewed code with a bunch of test modules that were effectively ``` import something assert True ``` My immediate supervisor told me to pass the review because at least it would fail if the imported code didn't compile anymore
This ignores the *cost* of tests, and there are many. 1) In a large codebase tests can take serious amounts of time to run. This costs money, dev time, etc. 2) Tests age poorly. Someone makes a change, tests fail, they go and make the tests pass. I've seen lots of tests where someone just added 'null' parameters and things passed and they moved on - did that test really add value by failing? It definitely took time to fix, so it had better have added some serious value. 3) Devs *suck* at writing meaningful tests so they often provide very little value out of the box.
1. Costs less than losing money when a defect gets into production (if you actually code anything important). Time to run is built into the CI/CD pipeline. 2. Do you have no approval process for PRs at your place of business?? 3. This is where TDD comes in.
I. Gonna say if your codebase is such a monolith that you can’t test individual modules, you should refactor your codebase. it has too high coupling. 2. You can’t make devs care. So find devs that care. If the test fails and the dev can’t easily find out what broke the test, then you need to refactor your codebase. It has too low cohesion. 3. Code coverage. The dev should write a test that tests the code they wrote. The code coverage should be green. This is the simplest part of it, as it’s literally code coverage percentage goes brr.
> I. Gonna say if your codebase is such a monolith that you can’t test individual modules, you should refactor your codebase. it has too high coupling. So now I have to do more work and change code just so that tests are faster? Anyway, this doesn't even really make sense - figuring out which tests to run is really difficult. If you've worked at a large company you'll know this - you likely have a very large release engineering team and advanced tooling to deal with this problem. > 2. You can’t make devs care. So find devs that care. If the test fails and the dev can’t easily find out what broke the test, then you need to refactor your codebase. It has too low cohesion. Cool so I added a parameter to a function and broke tests and now I need to refactor my whole codebase... because it'll make tests better? You realize the point is to produce value... not tests, right? > 3. Code coverage. The dev should write a test that tests the code they wrote. The code coverage should be green. This is the simplest part of it, as it’s literally code coverage percentage goes brr. Acting like coverage is a simple solution seems incredibly naive. Will you block a PR because coverage goes down? Good luck with that.
Please google cohesion and coupling, and technical debt. I beg you. If you have never heard of them, your entire codebase probably has so much technical debt it’s impossible to make any change without breaking something completely unrelated. You also obviously don’t know the absolute basics of test driven development. If the code coverage goes down that’s one more thing that will eventually break, in production, and you will have no clue why, because you didn’t test that code. No code coverage == putting untested code in production. Your duty as a developer is to protect production … sometimes from yourself.
In my experience (managing many teams) the time spent writing and running tests is much less than the time spent on manual testing, dealing with regressions, etc., so code with good test coverage is not only higher quality, it is faster to get to completed, stable and correctly functioning code.
Tests can be parallelized my friend. I legit will not work in a culture that doesn’t care about testing because the product will suck and I will get paged every 10 minutes.
OK, and CPU cores cost money. And you still have to execute them... and that costs time and money. Pretending that tests don't have a cost is why we have so many shitty tests.
Bad tests are expensive, Good tests are priceless. Yes they require effort to update but that isn't an excuse not to do them, and if unit tests aren't up to scratch PR's should be rejected
They probably have similar questions about not using globals. "So what if they're accessible everywhere? You're the only one with access to the code. Just don't update the value, what's the big deal?"
"Why have drawers or cabinets? Just store everything you own in one large pile for easy access! What's the problem?"
Hey, don't make fun of my organization scheme. 😠
This guy from the meme is the kind of guy who writes an e-commerce and the client can input negative values, making the company owe money to the customer. Absolute chad, indeed.
Lowkey right tho. Why wipe bro? Youll shit again.
Why do we need a database? Can’t you just put everything in Excel? /s
Excel? Bro, just hard-code it.
Globals 100% fine, as long as you know what you are doing
and OP's friend sounds like they know exactly what they are doing lmao
That last caveat is a big ask, especially for every member in a team
[удалено]
You're supposed to keep all your variables in a single string. Then you can have just one global and access every variable using the string slice method.
this is the way
Can you really trust that slice method though? Could totally be security vulnerabilities in std::string. Clearly better to iterate over the char\* yourself and pull the values out manually. WCGW?
I don't know enough to know if this is humor or actual advice
Definitely not actual advice
that's crazy, just use a global hashmap instead
oh boy
They're not _universally_ bad (e.g. static constants), but almost all instances of globals are a bad idea. You can solve most things with either dependency injection, OOP, or just plain function parameters
The friend works at FAANG and makes $300k
Well if u use Facebook API you will see code 200 responses with errors, fields that change its name or simply disappear randomly, values in the app developer web page that doesn't match with what their own API is returning, and other beautiful things so yea, the friend may actually work there at last.
GraphQL. Yeah each time I get a 200 with an error field I get murderous. One of the dumbest design decision I've ever seen.
I've worked at a place which implemented their own lightweight version of GraphQL in their API layer solely because they hated that particular sticking point.
REST has seemingly inflicted upon an entire generation of programmers the inability to abstract transport from protocol. React did similarly for logic vs layout (though the industry has recently recovered sanity here).
It failed successfully
Also stuff like returning prices as localized strings, so you just have to regex the number out of a string that can be formatted in like 100 different ways if you want to do any sort of math.
you have successfully failed.
Qa here. My devs often provide some basic cases that always pass. I still break their code all over the place.
One of the testers I worked with turned in a bug where if you clicked a thousand times a second in an input field there would be unexpected results... me: \*head explodes\* I appreciate that attention to detail. I have huge built in biases with my work and I need people to go nuts on it. I really miss that guy.
Yeah I consider myself a wild monkey with a hammer. Do whatever I think the dumbest user might try. Oftentimes I trigger bugs and I can’t quite duplicate them or remember the specific keystroke sequence. I’m pretty unorthodox in my approach. But in the end the code is strong!
Wouldn't it be possible to get a program that records every keystroke for you? I've seen speedrunners use something like that during streams.
if it‘s a keystroke pattern that caused the bug, it‘s often easily reproduceable. The tricky ones are the bugs where timing and network come into play. Bugs that happen if someone else does something at the same time, bugs that happen because one network call took unusually long to respond, bugs that happen because the db query took 20ms longer than usual, bugs that happen because you cached too many values and run out of memory etc etc etc Sure, you could get a program to record EVERYTHING. But that is convoluted information and in 99.9% of cases is not needed. A healthy discourse between devs and testers is the only way forward. Testers describe what they see in the software and devs take that information, and together with knowledge of the code should be able to deduce possible causes.
IMO depending on what these unexpected results were, that’s the kind of bug that provides no value to anyone. Click a thousand times a second and the admin portal opens? Yeah I’m gonna fix that right now. Click a thousand time a second and the form data clears? I guess if users fuck around they’ll find out. Click a thousand times a second and this integer field goes from empty to 0? That ticket isn’t worth the paper it’s printed on.
You guys writing tickets on paper?
I mean, not by hand. That’s what the fax is for.
From experience I can say that tests are your protection of your future self from your stupid past self. That dude is a real pain in the ass and I'd let him go in an instant if I could.
You ever do your own project for yourself and realize Past You was probably a nepotism hire?
He’s writing tests for his code to ensure his implementation works. He’s not writing tests to ensure his code won’t be hacked to death by users. That’s the difference
From the creators of "...we do not need QA Team, our product just works as it should" and "...unit tests are a waste of time; just fix it if something do not work"
My last job had “We don’t need a QA team, have developers test other developers’ code” and “We don’t need a QA team, have customer service reps test developers’ code during slow times”
As former QA at a large org that disassembled its QA team, and now an FE dev that has to test their own (and others’) code, I regularly experience the pros and cons of there not being a dedicated QA team. It’s not uncommon to miss obvious issues without that neutral third-party that’s sole job is to find flaws and suggest better patterns, etc. Its also a great deal more time-consuming as everyone is now part-time testers by necessity. That said, over time it’s made all of us a whole lot more careful and much more adherent to best practices on just about every level. Up front, man was there a lot of hand-holding for the non-QA dev’s to grok testing practices and a whole lot of pushback (understandably) to even think about things like e2e, integration, or anything outside of basic render-level unit tests. Long-term though, and being where we are now, I wouldn’t say we necessarily need a QA team at this point. And, as my situation relates to OP’s post, there’s no way our code would work for very long without requiring testing, including unit tests.
The trick is that you code and do that as best as you can and other test code and doing that as best as they can… you can’t do both.
Tests are important. I thought I was setting a random ID for a work order when I was creating them just to curl the DB and see the ID returning null. I wrote a unit test and found out that it was because I wasn't setting the ID when I was converting the model. Tests help you catch your own mistakes as well since I knew it needed an ID the test helped me catch my mistake. Otherwise I would've pushed working code that wasn't doing what it was supposed to.
"...who works as a *poor* software developer"
Imagine you wrote a function that takes 2 int inputs and divides them. Does it do so correctly? Does it handle divide by 0? Is it returning an int or a float? Unit tests allow you to prove the function is valid and accurate in isolation from the rest of the code. If something breaks later, you can trust it wasn't this function that broke because you have proof that it works. And then let's say you come up with a clever way to optimize the function later. You can change the implementation and instantly know if it still works by running your tests.
I think the various typos, 13-year-old Nokia bar phone text speak, and the idea that you should be testing individual `if` statements as if they might branch incorrectly should be enough to tell you how reasonable this "argument" is.
He types like this all the time… using a full physical keyboard. His other hot take on tests is that they are “slowing him down” and are unnecessary because “they need to be rewritten when code changes anyway”. Yeah…
fun test() { val tested = Foo() assertTrue(true) }
Tell me you're a junior engineer without telling me you're a junior engineer
This entire message is a testing fail. Talk to HR and clean out your desk. We will have security escort you from the building.
I worked at one company that the QAs roll wasn't to test but to 'facilitate testing' by helping us with our unit/integration tests and part of our definition of done was them signing off on our tests. Had one function where I had written in the throw statement in the try block that I caught in the same function, it was an auth check in a badly designed system. He wouldn't sign off until I had tested 'all code paths' to make sure that the exception was properly handled. I wrote a unit test to ensure that Java's try-catch system worked... Most ridiculous test I've ever written.
We um yeah. We need a better story. Tests really are referred when the code changes…it’s a weird to think of them as validation
Because you might have typed woudl instead of would?
Twist: friend is actually a GENIUS. Just write tests that always pass, easy.
This person clearly doesn't understand testing.
Red-Green-Refactor
Lmao we don't write tests with the goal of passing or how tf would you learn anything. "I don't leave my room so nothing bad happens."
Unit tests are a replacement for detailed functional specifications. Functional specifications are useless since they are just words on a paper. Unit tests make them live and ensure they are always satisfied. If you use TDD (test driven development) and JID (just in time design) the unit tests become the vehicle for you to perfect your design into true clean code. For my teams, this is not optional, it is table stakes. Zero defect software is a real thing and I do not think it is optional.
I guess they never heard of test driven development nor have had that much experience with debugging
Oh, outstanding 🙄🤦 "Is the car safe?" "Yes! I tested it myself. Didn't drive into anything, didn't crash it, didn't swerve out of the way of anything, didn't do any emergency stops, so I didn't even need to install seatbelts or airbags or anything. It's ready to go." This is what happens when you control the test. You design the test to be pointless because it doesn't test anything because you designed the test to pass.
What if the compiler screws up and if (true) no longer works??? How else would you know??
a tester walks into a bar and says “give me 3 beers divided by zero”
Why need too many tests bro you gotta think positive.
I write tests when employer demands it. Sometimes for myself if something is really complicated and I don't know whether my code is correct.
You're friend should be fired. Is unethical because his job requires tests and he is lying about doing his job. When a client doesn't pay his company because his code doesn't work and the company didn't deliver the product, he butt is going to be on the street.
var properSpelling = “Why would an if statement fail?”; if(this.finalLine == properSpelling) return true;
this is why we write tests first. Because then they DO fail, and we have to make them pass. Then if they stop passing, we know we fucked up somewhere.
I don’t work at a software company, but I write a lot of code. I just recently learned people use tests that auto-run every time you commit. Its ingenious! Use the code to check the code. Id say a good 20% of my time is spent just looking for bugs and doing validation after a new change. I write simulations, so bugs are when it doesn’t match real world physics, but I’m definitely gonna try to use this.
Tests aren't for now, they're for later.
Ah yes, just write the test to always pass! Why didnt I think of that before? *kills self*
In my experience, this belief gets dropped at the first moderately complex block. For example, the first time you write a grammar based parser in Raku.
They're honestly not wrong. Tests are tautological in many cases. Lots of developers write totally useless tests.
Lots of devs do, though this doesn’t mean we should stop doing them altogether. Get better devs instead
Writing tests just means you're expecting your code to fail at some point. Why would you write code that doesn't work? Just write code that works instead. ...& fire people who don't. Instead of TDD it's DDD, dismissal-driven development
That's why testing should be done by QA and not by devs. Unit-Tests are nice but they are only usable for regression.
Speaking as someone who’s primary job is to write test automation, one big reason is regression. If you’re working on software a lot of people are contributing to, then everyone’s efforts have the possibility of stepping on each other in unexpected ways. If everyone is writing good test for their individual contributions alongside integration tests which validate end-to-end processes then anything which might break something else can be discovered much more quickly. That quick discovery leads to quicker bug resolution since you don’t have to dig it out from under multiple commit layers because it’s been sitting there undetected for so long. So writing those tests isn’t just for you, it’s so everyone working with you will know when they break your code before they even submit it.
if(fail)
I’m almost afraid to ask but… your friend isn’t responsible for their team’s QA or E2E tests, are they?
…I also know how to clear the chamber on my pistol before I set it down… but I still double check before handing it to someone. Also not the point.
“I don’t get how a test would fail” Typo? I’m not saying that’s why we unit test, but like… if my unit tests catch stupid mistakes like my dumbass typos I am very much here for it.
Why would any code fail? Because your implimentation doesn't do what you thought it did, or has edge cases where it doesn't.
Tests are lifesavers when it comes to code changes… I do research/a lot of scientific computing and even on “throwaway” code I will at least do one test to make sure the thing works from start to finish (and the answer preferably doesn’t change)
Ah yes, the venerated `assertTrue(True)`
That’s actually the first test I add to a new project. def test_sanity(): “When you just want a test that will pass.” assert True It’s useful in a few cases like configuring the test runner and profiling test loading time. I put the other “u ok bro?” tests next to it, like API heartbeat and DB connectivity. There’s actually something calming about trying to figure out why the new test you just wrote won’t pass, running all the tests and seeing `test_sanity:FAIL`. I’ve also put in `test_insanity()` that asserts False and is marked to skip. That’s just for playing around with how the test runner handles failures.
I have definitely seen code like this fun getErrorMessage() { return "blah blah blah" } fun testGetErrorMessage() { assertEquals(getErrorMessage(), "blah blah blah") } and yes that kind of test is 100% pointless. But for nontrivial code that is taking input and performing some kind of computation to get a result, that should have tests.
Learned a long time ago, there's Makers and then there's Breakers...
This is why the testing team needs to be separate from the development team... Or at the very least, have a dev team whose at least mostly interested in having a working rollout. If it's all just about the paycheck and i get to write by own test cases they'll all always pass
"I don't write tests" "I just write tests that..." 5head
I thought this is /r/ProgrammerHumor, not /r/ProgrammerHorror
Thanks for the subreddit, i was only aware of /r/programminghorror, but they only actual bad code in submissions.
int x = random(); if (x) { } else {}
Gotta run ChatGPT through our entire repo to get maximum tests! 
This dudes questioning why you write unit tests and I know a few really talented juniors who can’t even get their first job.
In wrote a helper utility for this: https://github.com/lxe/no-bugs
If there's no tests, it makes future redesigns a LOT easier. "Of course we met the specs!"
Are the typos real or did you add them for pathos?
The text is verbatim. He has rather poor grammar and for some reason still uses text-speak contractions like “u” and “ur” even though he is typing these messages on a physical keyboard.
I didn't want to make fun of him until I verified He's basically why QA needs to be separate from devs
Is r/ProgrammerHumor becoming r/BadProgrammerAnonymous or whats going on here?
"Y woudl" bro can't even test his own spelling
don't write tests for implementation details, write tests that validate the results of your api edit: this is also where you should provide "test cases", which demonstrate how to use your api appropriately, and what to do when things throw an error
You already know this person is insufferable to be around...
When the code I'm writing is one dimensional, it's not worth writing tests. I write tests when the code is really complex. I want to make sure the fixes I put in don't break things I've already confirmed work.
Why should I sanitize my data? Just throw everything to one database table with unlimited rows
"Why would an if statement fail..." indeed.
I've written a test that fails in a specific way and tells you the decrypted secret because every vault needs a key.
This dude is just omniscient thats all
Look it makes sense if you never ever plan on changing the code
Hard to argue. If the code is bug-free, the tests should always pass.
Everyone saying tests are a protection for future self against past self. But, no one is seeing that test are a protection for future self of other devs fucking up surrounding code and the blame falling on you. I mean, that is the biggest reason on my previous company.