I'm dumbfounded by the number of devs that don't test and stories of devs that don't test

[-]

rollie82@reddit

Not testing what they wrote? Or not writing automated tests?

[-]

Light_Beard@reddit

Manager: "Sure as long as we release when we said without consulting you"

[-]

WenYuGe@reddit (OP)

Moment of silence to devs who work in these places.

[-]

photosandphotons@reddit

I thought I worked in a company with some bad testing practices but it’s nowhere as bad as this.

And most of my tech contacts in other companies are more sophisticated…dealing with FAANG and a tier below here.

[-]

rocketbunny77@reddit

No. Our product owners know why tests are good and specifically make sure they're part of the definition of done

[-]

Cheraldenine@reddit

Where I work the product owners are domain experts, which is nice, but with zero knowledge about good software development.

[-]

4THOT@reddit

If you're the software development expert it's your job to say "this will require testing, we will need dedicated to it" instead of cry on reddit that management isn't reading your mind.

[-]

hippydipster@reddit

Budget for it? Its faster and cheaper to build with tests if the project scope is anything beyond a couple months of work.

[-]

Maxion@reddit

Many projects work in such a way that the client ( or som idiot they hired) buils up a team from random consultants. This PO, which sometimes is the client, sometimes an external PO, handles the project planning. When you as the lead add tickets related to testing, or acceptence criteria related to testing, the PO/client shoots it down and requires you to remove that.

Projects IRL often have a scope of 3-6 months at a time, even if all parties really know that the project will last 2+ years.

Reality is very sad :(

[-]

hippydipster@reddit

3-6 months is beyond a couple months, and so it will be cheaper and faster to build with tests. You don't write tickets for writing tests, because it's part of normal dev work, just like I don't write tickets to write a class to inherit from some other class.

Of course, if it's not a unified team working together and agreeing on how to work, then very little is going to function well anyway :-)

[-]

Maxion@reddit

Of course, if it's not a unified team working together and agreeing on how to work, then very little is going to function well anyway :-)

Ain't that the truth, a lot of coding advice is written with the baseline that all stakeholders are a) rational b) competent and c) present. Reality is not always like that.

[-]

hippydipster@reddit

What advice would you give the irrational and incompetent?

[-]

Maxion@reddit

Learn to live with the non-perfect. Learn how technical (or not technical) the people(s) in charge are, and take advantage of that. Either to try to convince them every now and then to sneak in some refactor or some testing. Or, make something overly complicated and claim it takes a long time, and then sneak in some tests or refactoring.

[-]

hippydipster@reddit

this sounds like advice to me - are you saying I'm irrational or incompetent?! lol :-)

[-]

Comprehensive-Pea812@reddit

writing automated tests is not foolproof though.

had a coworker who refuse to manual test and spent days going back and forth with QA for something that can be easily discovered by manual test.

[-]

MassiveInteraction23@reddit

What do people mean by “manual” vs “automatic” here?

Are we talking regular, fixed value tests vs property testing and fuzzing?

Or a human plays with the program and checks it out vs any kind of tests written in code?

[-]

wk_end@reddit

The latter; I don't think I've ever heard "regular" unit/integration testing referred to as "manual".

In any case, the article is pretty clear:

As I was looking at possible modifications of some of the code he had written, I couldn’t find where it was being tested. I asked tactfully if he could point me to the related testing code so that I could make sure I wasn’t going to break any expected behaviors. Much to my surprise he told me he didn’t have any tests written for it.

[etc.]

[-]

hippydipster@reddit

Nothing is foolproof.

Don't hire fools.

[-]

Comprehensive-Pea812@reddit

funny is. that ex coworker of mine was considered top performer, yet still uses a b c as a variable name.

I guess manager should learn to spot smooth talker.

[-]

narnach@reddit

We talk about this in person at meetings, over drinks, at the bowling alley. It never changes.

[-]

Kevinw778@reddit

What else would you have to shoot the shit about, if not for people not properly doing their jobs?

[-]

rollie82@reddit

Thin line between confidence and hubris.

[-]

wrincewind@reddit

Nah, couldn't be me. I'm too powerful to be affected by hubris.

misunderstood my response. I meant that it's fair enough to have that grievance if it's their job 😂😂 and not if they're not being paid

[-]

tomvorlostriddle@reddit

You get back a response - apostrophe issue fixed.

Now it shows an error message to the user saying

You are invalid

Bug sent for rework

Error message that roasts the user instead of allowing login is not acceptable

next iteration with error message

Your name is invalid

When I was a team lead, I did push hard on people doing good reviews, and it worked. They would take longer, but a lot of issues were found and dealt with. We also had QA do a run through before MRs could be approved and merged.

But it does take a culture that is serious about it and a lot of devs are lazy and entitled. We see it here in these types of threads where people make it sound like any sort of process is unnecessary "context switching" and a waste of time. Meanwhile, their job is churning out React components.

[-]

Turbots@reddit

Agreed 💯

[-]

Dx2TT@reddit

The truth is that the majority of devs don't know how to dev. The problem is that, also, the majority of dev managers, don't know how to dev manage so they can't figure out which devs are which because they can't determine when a problem took a long time because its actually hard or it took a long time because the dev fucking blows.

[-]

wrincewind@reddit

I don't like solving problems twice and i definitely don't like being whined at by end-users, so you can guarantee that i double-check my code does what i think it does. (....most of the time. sometimes i forget to test every aspect of a big change, but at least i'm trying!)

[-]

jamart227@reddit

As a QA responsible for testing the offshore devs code, this is the most painful part.

Made a bug fix request to change form email length validation to from 355 to 255 the other day. Later that day I get a message that it is fixed, I check the form, now the validation length is now 325555...

[-]

bumblejumper@reddit

That's not what you intended? /s

[-]

BasicDesignAdvice@reddit

Any advice on finding "smaller" gigs? Everything I see is big corporations. Not even as many startups these days (and it's always seemed like you need to know someone for those).

[-]

bumblejumper@reddit

Network.

Sounds like a culture problem. There are tools (like husky, githubactions) that can allow you to prevent a code from being committed or a PR from being accepted if code coverage isn't x, or unit tests aren't created, etc

[-]

bumblejumper@reddit

Honestly, this has happened to me when working one-on-one with guys I hand out with on a personal level, and teams I've hired overseas who I have nothing but a working relationship with.

It just feels like most devs look at the code, adjust, and assume the error has been corrected because the code looks right.

Looking right isn't enough. That's why testing exists.

[-]

Pious_Atheist@reddit

Also, no excuses in the era of AI copilots.

[-]

mccoyn@reddit

Even something as simple as, "Hey guys, the form validation won't allow for last names with an apostrophe, can you make a fix allowing this?". You get back a response - apostrophe issue fixed. You test the form - apostrophe issue NOT fixed.

I know this is a quick example, but it isn’t a god problem description. Maybe there are two apostrophe issues, the dev fixed one and you tested the other.

The_No_Lifer@reddit

I wrote code for manufacturing equipment for a med device company. We didn't do any validation until the initial qualification, which is needed before it can touch product that goes inside someone. Once it was qualified, ANY change needed to be validated before it was qualified again.

We would usually take the machine down, test, revert to the old, write the validation docs, then install the updates. It's horribly slow and we would often include QOL upgrades with bugfixes because they wanted the QOL for months but now have justification to take the machine down

f10101@reddit

Yeah, that's deranged. They must have misinterpret "change" in the QMS they cribbed. Easily done, I guess - the documentation is very dense.

[-]

BigHowski@reddit

Same with ERP here. I don't recognise this to be the case in my industry at all. Sure you occasionally get the odd "fixed" and it turns out not to be but mostly we have so many processes that as long as the process is accurately described the mod/fix does what it should

[-]

Loves_Poetry@reddit

I have also encountered this situation way too often and it is shameful to have to address it

I see a PR with changes that claim to fix something. I see something that catches my eye that I find suspicious. I check out their branch to see if it really works. App crashes on startup.........

Yes, they just threw it over the wall without even bothering to start the app. I wasted a lot of time carefully reviewing something only because some other dev was too lazy to even start the app they are developing

[-]

no_spoon@reddit

It’s not up to the dev to decide tests need to be written. It’s up to the project spec and thus the PM. Clients don’t give a flying fuck about your tests. They want to know whether it can be done on time within budget. Do you want to be the person to say “it’s going to take me twice as longer because I always write tests”.

lol. Wow. Nothing personal dude. I just see your type often. You’ll fit nicely in the corporate space where you’ll feel like you’re making a difference and your boss is happy, but really you’re just a number. You’ll have the capital to allow for your over engineering, but that could change so I’d be careful.

[-]

BornAgainBlue@reddit

I have had the same experience, it really affects trying to get a job when you have to admit that no job you've ever had implements unit testing. I FINALLY got a job that used it, and if course the downsized and I got laid off.

[-]

Scroph@reddit

Sometimes the fix doesn't get deployed to the right env, other times it's caused by a regression. I used to include screenshots in the corresponding Jira ticket before sliding it to the next column just so that I don't lose my sanity if it gets brought up again

[-]

MasterLJ@reddit

I remember counting the "cycles" at a previous employer.

A "cycle" is where I report a bug, they claim they have fixed it, I go to verify and it wasn't fixed.

It was 18 cycles before I lost my cool. My last day at that job, it was over 50. Exact same bug. Each cycle took me about an hour.

[-]

deong@reddit

That’s been my consistent experience with unit testing. People go all in on test coverage, and a bunch of shitty programmers write endless junit tests to make sure that integer addition and the built-in ArrayList methods work.

[-]

Loves_Poetry@reddit

Testing built-in methods gives zero coverage, so I have no idea what those devs are doing. But they're not creating more test coverage

[-]

deong@reddit

They're probably not directly writing a test on ArrayList.add. They've probably written a bunch of trivial things like getters and setters and methods like "addCustomer" that looks like

public void addCustomer(Customer c) {
    this.customers.add(c);
}

and then written unit tests for all that stuff. Which is equivalent to just testing the built-in, but obfuscated just enough to feel warm and fuzzy about it.

[-]

hippydipster@reddit

You need better mentors then.

[-]

deong@reddit

I don't necessarily disagree, but "you need to be better" is kind of a universal solution to any problem. It's kind of hard to put into practice consistently though.

Like if you have great engineers and great mentors and great management structures, almost any development process works really well. If you don't, you might need help from tools and processes, and I just think that a major focus on unit testing hasn't necessarily seemed all that successful in filling that role in my experience.

[-]

hippydipster@reddit

There's frankly a lot to learn, and it shouldn't be surprising that the words "unit testing" do not convey the full information necessary to understand how to write automated tests.

if you have great engineers and great mentors and great management structures, almost any development process works really well.

That's not true though. The best engineers in terrible processes and environments can't do very well either. It's like saying geniuses don't need a scientific method, empirical experiments to verify their hypotheses, double blind testing, peer review, etc. But, of course they do. An idiot can't do science with all that, but a genius can't do science effectively without it. It's all quite similar.

Can you, or anyone, write 40,000 lines of code without ever running it and deliver and have it work? Even a "great engineer"? No. You run the code to make sure what you wrote works. That's testing. Most likely, you run the code A LOT to test your work. Automating that just makes sense - speeds up the process and makes it more effective.

[-]

deong@reddit

That's kind of a dumb strawman to set up. I'm obviously not suggesting that you not test or even run your code. I'm specifically talking about the culture of unit testing and test coverage. You can be an incredibly good tester and never write a single unit test. It will almost certainly be easier to maintain correct code over time if you have some automated tests in place, but for most of the history of software, we tested stuff by just writing code and doing ad hoc functional and integration tests. I don't see where software got any better when automated testing became de rigeur in the industry.

Again, not saying there's no value in it. There is. I'm saying it isn't a replacement for just making sure your software works, and there are lots of people out there who think that just writing tons of unit tests accomplishes that, and it doesn't.

[-]

hippydipster@reddit

there are lots of people out there who think that just writing tons of unit tests accomplishes that

This is the way.

TestContainers are a real game changer on this front. It's worth making sure you can run them on the build server.

I still do unit tests of units that are non-trivial/where I want some insurance in the future that changes won't break expectations, but it's way too easy to spin up most external dependencies in testcontainers these days not to.

[-]

taedrin@reddit

Unit tests are fine. But they aren't a replacement for integration tests.

[-]

LiquidLight_@reddit

Can you scream that at my entire leadership chain both business and tech? Because this project is like 7 years in and we have no integration tests, no end to end tests, only unit tests and manual testers.

[-]

TangerineSorry8463@reddit

You can have some sort of SonarQube or other static linter that checks which lines of code are actually executed.

[-]

jtinz@reddit

How would that help?

Here's an example: On navigation, a NavigationService provides a value through a pipe. The "page" in the SPA subscribes to the pipe and expects a value. Without it, the page won't load. Only the navigation occurs before the page is created. Therefore, the page will never receive a value and as a result won't load.

The test implements a mock NavigationService. It's mock pipe will provide the value on subscription and the page loads just fine.

[-]

BenAdaephonDelat@reddit

I've had 8 jobs as a programmer. I've only ever done automated testing at 1 place. I would love to have done automated testing, but most jobs have pre-existing code that wasn't built for testing and the managers are never willing to take on the tech debt of making automated testing work.

[-]

ThisIsMyCouchAccount@reddit

I was on an internal team making a system that pushes/pulls data from all our other business systems.

It was pounded into me that this *had* to be correct.

Great. Can I write tests?

Absolutely not. I guess it's just better to manually test workflows by resetting data in the database or just using one piece of manual data.

Excellent-Cat7128@reddit

Do you actually start skipping these tests? I've never had that happened. Maybe a test that is no longer needed goes away, but otherwise every automated test that gets added stays in the pipeline. And invariably, at some point in the not-too-distant future, it fails and a prod issue becomes a staging issue.

[-]

RupertMaddenAbbott@reddit

The post already addresses this point.

This is a bit like standing up off the couch and claiming to have exercised. Whilst technically correct, it distorts the meaning of "exercise" into something that most people would find unrecognizable compared to the real thing.

Similarly, its not just "not writing automated tests". Its watching somebody do the equivalent of standing up off the couch and claiming to have exercised. The value of this "testing" is low that it barely qualifies as testing and to accept it as such distorts the very meaning of the activity.

Tests (manual or automated) can provide three distinct pieces of value:

They verify that something works - most people get this and do this part when testing manually
They specify how something should work - manual testing can only achieve this if you are writing down all of your test plans
They confirm that something still works, later on - manual testing can achieve this with proper test plans but it does not scale to the number of behaviors that are often important

It's not that manual tests are never correct - sometimes that is the cheapest way to test something. It's just that you can't leave your test plan in your head and on your dev machine, unless you are happy that the behavior is throw away, or that it is acceptable for it to be regressed.

So when we say "this hasn't been properly tested", we don't literally mean that a developer hasn't gotten off the couch. We mean that claiming this to be "testing" says more about their understanding of that activity than it does about the value that has actually been achieved.

[-]

gelfin@reddit

Doing neither is shockingly common.

So, I don’t think it’s a secret to anybody in here that SWEs often have a really bad case of “smartest kid in class” syndrome. “I can see no reason this would break” is kind of the default position among many of them, to the point that look and make sure doesn’t even occur to them. I once worked at an org that had a sort of “honor system” policy baked into the pull request template. The dev had to check boxes confirming they had done commonsense things like:

run it locally
look at the behavior and confirm it works
write unit tests for new behavior
run the relevant unit tests
write testing notes as needed
deal with linter issues

This was more effective than you might expect. People who were “too busy” to sweat the details more often than not forgot to deal with the checkboxes too. There were few cases where people outright lied, because dishonestly is not the failure mode here. Overconfidence and lack of rigor is.

A close friend is a QA lead. She’s been working for over a year trying to get the organization on track doing proper automated testing, but is constantly hamstrung by the rest of the dev organization. This is an org with a culture of testing things in prod, just tossing code over the wall, keeping low-confidence initiatives secret (individually or within the team) and making drastic changes without telling anybody. The result is an ongoing quality dumpster fire. My friend is an experienced automation engineer, but she’s reduced to playing a schoolteacher nagging students into doing their homework just so the product can limp through manual testing. I can’t tell you what product they’re producing without risking identifying details, but it’s one where failure in prod can be a pretty big deal. Like potentially “human lives” big in the worst case. I am actively repulsed by management, but I have never wanted to step in and knock an organization into shape more than this one.

[-]

Private_Kero@reddit

Can you give a concrete example for your negative-value tests?

is it about things assert func() == value?

My biggest hurdle in testing are APIs, because I still don't quite understand what mocks are good for and I have the impression that you build fake (mock) objects here that supposedly test something (feels like cheating).

My impression is also that there is little content, especially with regard to testing, which provides non-trivial examples with the typical add(x,y).

[-]

Fearless_Imagination@reddit

I don't have time to write up a non-trivial example right now, but:

is it about things assert func() == value?

No, it's about writing tests on implementation details. For example, you factor your code into a few private functions, then write tests on those specific functions. Then you later decide to refactor those functions into a separate class... and now all the tests you wrote on those functions are failing, despite the fact that you haven't changed how anything actually works. But now you have to check if these tests are indeed only failing because you wrote them on the wrong level of abstraction, or because you actually did accidentally change behaviour while refactoring.

My biggest hurdle in testing are APIs, because I still don't quite understand what mocks are good for and I have the impression that you build fake (mock) objects here that supposedly test something (feels like cheating).

Mocks are for the things that are external to your code, like another API or your database. You use dependency injection to inject some kind of adapter for those things into your code, and then mock that during your unit tests. The main benefits are that this allows your tests to be fast (no latency) and independent (don't need the external API to be up), and allows you to more easily fake error responses. The downside is that this approach doesn't quite cover everything and you will need to test with real implementations as well, as they real things might behave differently than your mocks of them, although that is usually done in a different set of tests.

[-]

IAmMuffin15@reddit

You don’t even have to right tests. Just use the debugger.

[-]

Alternative-Link-823@reddit

A test should ideally only test one fact and not break when something else is changed

You ask to do an experiment where you track your defects over time. As you add tests you can check to see if the number of defects go down. I'd imagine the more testing you have the less defects there will be.

Then you have something to measure against. Once you can measure it then it's much easier to prove value to business.

This is a general approach to justify anything to management and be able to demonstrate value.

[-]

deeringc@reddit

I'm very much in the pro-test camp, but one problem with this is that a lot of the benefit of the tests I write today is that in 6 months when I or someone else makes a change in the code, or fixes a bug, my 6 month old test prevents a regression. There are immediate benefits to testing too, the code I write today will also have fewer defects and have a better structure but a lot of the benefits are medium term. A sceptical management team won't want to run an experiment over years.

[-]

Cheraldenine@reddit

I'm very much in the pro-test camp, but one problem with this is that a lot of the benefit of the tests I write today is that in 6 months when I or someone else makes a change in the code, or fixes a bug, my 6 month old test prevents a regression.

And a lot of the cost of tests is not in writing them initially, but in the many times afterwards where the tests needed to change because the behaviour of the code changed.

To me whether tests are worth it really depends on the kind of code we're talking about. The more we're in the domain of library-like code, well defined functions, logic -- test test test. On the other hand, frontend code that sits on top of everything and is basically concerned with how everything is shown on the screen -- people will test it by eye anyway, and it changes far too often for automatic tests to be worth it.

[-]

Maxion@reddit

I generally try to at least shove unit tests into frontend projects, even when the customer tries to keep me from writing them.

I try to be quite strict with keeping components to just drawing UI, and keeping business logic to service classes or state management stores (depending what flavor of SPA we're working on). This way its semi-easy to write unit tests for the business logic, but you can keep the frotend UI components untested.

[-]

deeringc@reddit

See, I don't think it's right to view that as a bad thing. The test isn't being "fixed", the contract of the production code is changing so it's absolutely natural that the corresponding test gets updated to match the new contract. That's a feature, not a bug.

Now, some tests are badly written where they end up testing the internal details of code rather than the external contract, but that's another matter.

I'm talking about properly designed tests - they give you the safety net that ensures that a contract change is indeed intentional, rather than accidental, and locks in the new behaviour to ensure that it doesn't get broken accidentally in future. This is exactly the kind of deliberate change you want in a system.

I wouldn't say that preventing regressions is rare - in my experience it happens often. It's just a silent part of the iterative dev workflow. Make a change, get a test failure because of some obscure requirement I was aware about 2 years ago when I wrote the code but had forgotten, amend the code with that in mind and iterate again.

[-]

Cheraldenine@reddit

We did that, and spending time on writing tests was nowhere near worth it. We had a few defects but they were all of the type where the developer misunderstood or forget about some requirement, and thus wouldn't have written a test for it either.

(this is frontend React code that is 80% CRUD, 20% a bit more involved)

[-]

RackemFrackem@reddit

How is that off topic?

[-]

headhunglow@reddit

I'd recommend lying. If they ask "how long will this take" you give them a timeline including running tests, setting up a CI environment (or whatever needs to be done to automate tests, never done it).

[-]

justinlindh@reddit

"Are you cool with production outages and downtime? Me neither. We should make sure things work as intended before the next release. Do you want to hire a ton of people to manually press the buttons and make sure all this complexity works (which won't scale linearly as functionality is added), or allocate time to engineering to automate (or at least minimize) that?"

If that fails, unless the software you're working on is truly "simple", the company is a ticking time bomb.

I've never had to make an argument in favor of testing before, though... having to do so is a pretty big red flag.

[-]

deus_pater@reddit

Who are all these engineering managers who don't understand the value of testing, and why on earth do I not have a job? lol

[-]

Gwaptiva@reddit

It is what they pay me for: developing software includes writing tests; in fact, 80% of your time consists of thinking of ways to test the features you are coding

[-]

Drumheadjr@reddit

Show them some statistics and studies etc.

Management loves statistics

Seriously though, I have been watching this happen recently in the company I work for and the biggest way to get the higher ups to buy in is to have external publications and studies and data that goes into the stuff in a "We spent 2 years doing infrastructure and our productivity increased by 300%" kind of way, with data and proof to back it up.

There are some books that are floating around out there that have this sortof thing going for them. But looking at publiciszed pieces like "how google does QA" etc. is what you want to look at if you are trying to sell these ideas. Management want's to be google, because google makes a ton of money. If you are pitching stuff and you can say "this is how google does ____, here is a thing you should read from google on how much money it saved them over 3 years", that is how you get buy in from management.

just understand that if you can't deliver you might be out of the job. there is a risk in rocking the boat of course.

[-]

Feeling_Employer_489@reddit

I gave up trying. I test anyways, probably about half the time, when I think it would help me develop faster and I think the task was over-or-correctly-estimated and there aren't other high priority things to fix.

The #1 reason is just inexperienced devs working at garbage-tier companies. Either startups/scammy consulting companies where noone has any experience with testing because they're new, or legacy companies where noone has experience with automated testing because they didn't do that in the old days.

I've reviewed too many (trivial ~30 minute) take-home submissions where we asked the applicants to test their submission and they either don't use a testing framework, or document a manual testing process.

And this often is from developers with multiple years of experience and/or "senior" on their resume.

[-]

nachohk@reddit

I've reviewed too many (trivial ~30 minute) take-home submissions where we asked the applicants to test their submission and they either don't use a testing framework, or document a manual testing process.

And this often is from developers with multiple years of experience and/or "senior" on their resume.

If you didn't explicitly specify that a testing framework should be used, then that is an obnoxious expectation for an interview assignment. Part of being "senior" is knowing better than to waste time on automated tests for a 30-minute throwaway piece of code. I say this as someone who writes automated tests for non-trivial code as a matter of habit.

[-]

TommaClock@reddit

The point of the exercise is to demonstrate a basic knowledge of best practices (and the prompt specifies as much).

Wouldn't be much of a test if all of the answer were specified now would it?

[-]

There is no perfect method of filtering candidates. Someone using a method which isn't leetcodes isn't a troll. This method has worked to hire some fairly good candidates.

[-]

ReversedGif@reddit

Testing frameworks are not an intrinsic requirement for anything. If you have a compiler for a Turing-complete language, you can do anytthing.

Kids these days...

[-]

ProtoJazz@reddit

You don't setup a full ci instance for your interview assignments? Damn.

One of the early interview assignments I did that I remember getting a frustrating reply to. It was a poker hand evaluator. Big fuckin words on it saying treat this like a real work assignment, and "ONLY IMPLEMENT THE FOLLOWING HANDS" and gave a small subset of possible poker hands.

Very specific about doing only those ones. My guess was there'd probably be a live portion and you'd build on it. Or maybe they just didn't feel like looking though a bunch of shit and got the idea after the first few.

One of the first things they said to me after I handed it in. "Well why didn't you implement all of them?"

I told them the assignment specifically said not to. They told me they wanted people who were willing to go above and beyond.

And I don't know about you, but I don't consider going above and beyond to be doing something you were specifically told not to do. If someone's up on a ladder and says don't move it, and you yank it out from under them, they're gonna kill you. They aren't gonna hit the ground and congratulate you on going above and beyond.

[-]

nachohk@reddit

I told them the assignment specifically said not to. They told me they wanted people who were willing to go above and beyond.

Absolutely insane.

I have kiboshed otherwise promising interview processes over smaller, whiter lies than that. There is a level of stupidity that is hard for me to grasp in beginning one's professional relationship with a job candidate by giving them a reason to distrust the things you say. If they'll lie about the requirements for the work they want you to do, what the fuck won't they lie about?

[-]

TommaClock@reddit

I could explain further but I think next time I'll just tell Reddit that I hire on leetcodes.

[-]

dweezil22@reddit

I went to a large financial company, took a repo with zero tests and wrote a few hundred unit tests. They all worked, and while code coverage was still at best 20%, it was something. I asked all the other devs to follow my lead and write tests.

Two weeks go by.

"Dweezil, you broke the build"

"Oh sorry [takes look]. No I didnt break the build, you changed the behavior of a function without updating the test. You need to fix the test."

[1 day goes by]

"I don't know how to fix the test. How do I disable it?" [tells them]

I went back and fixed it later.

Repeat 20 times, and I stopped going back. Wait two years, 80% of the tests are disabled. Nobody got fired, and mgmt accepts the near-zero dev velocity for the ppl that weren't offshored to lowest bidder Cognizant folks. So... yeah...

My new place we write a lot of awesome tests and it's pretty cool.

[-]

fubes2000@reddit

The number of times a dev has asked for help, listened to my explanation, looked me in the eyes and said "thanks", and then gone back to their desk and done sweet fuck all is quite frankly staggering.

Especially when they have the balls to show up the next day and complain that the problem hasn't fixed itself.

[-]

Frown1044@reddit

Maybe this a communication issue? If many different people seemingly don’t understand what I just explained, then it’s probably a problem on my end.

[-]

WearyAffected@reddit

If someone doesn't understand what was explained they should say so, not pretend they do. Proper response to not fully understanding is to ask more questions and continue the discussion whereas some people just nod and you can tell they don't really understand.

So yes, it is a communication issue, but from the person who is pretending they get it.

[-]

Frown1044@reddit

Asking for help is rarely an emotionless conversation that only stops until the asker understands the explanation.

If you're fixing tests all the time, you're probably writing bad tests.

If your code is hard to test, you're not writing testable code.

Inject dependencies, where possible. Test integrations is possible. Mocks are a smell (sometimes). End to end tests are amazing, but slow. Unit tests are fast, but often not useful.

[-]

sparr@reddit

If your code is hard to test, you're not writing testable code.

Most developers have no exposure, let alone training or practice, on what makes code testable. The terms are entirely foreign to them.

[-]

booch@reddit

This is true of a whole host of topics. Many devs have no experience or skill at

Writing useful comments in code
Writing documentation
Writing testable code
Writing tests for code
Naming things
Writing simpler code that's easier to maintain
etc, etc

The solution is to force them to learn the above things.

[-]

pemungkah@reddit

Please do not get me started on people who claim all code is “self-documenting”, or that “the comments just get out of date anyway”. Yes, they do, Sparky, if you’re a lazy goddam twit who does half their job.

[-]

booch@reddit

Yes, they do, Sparky, if you’re a lazy goddam twit who does half their job.

Exactly that. Part of your job as a developer is to keep the comments up to date. If you can't do that, then you can't be trusted to make sure the code correctly implements the requirements, either.

Even the best code, without comments/documentation, only tells you what the code does, not what it is intended to do. And those could be two totally different things.

[-]

pemungkah@reddit

And why. So many uncommented code problems are caused by well-meant changes that were done because something “looked wrong” but wasn’t.

Spare everyone the probably-repeated error and just say why it’s done the way it is. Maybe someone can indeed fix it better later, but at least they’ll know what’s going on before they try.

Chesterton’s Fence:

There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”

[-]

KevinCarbonara@reddit

A good type system eliminates a whole class of errors.

This is why python devs are always so surprised that C#/Java devs don't have to write anywhere near as many tests

[-]

kuribas@reddit

Enforcing type hygiene in python helps (rejecting pyright errors in the build). It’s an uphill battle, I keep hearing how typing doesn’t solve problems etc. . I am the only one that wants to get rid of all type errors in our place.Th alternative is 100 % coverage.

[-]

Jonathan_the_Nerd@reddit

Enforcing type hygiene in python helps (rejecting pyright errors in the build).

I would like to know more. How do you enforce types in Python? Can you point me to educational materials?

[-]

Asyx@reddit

Yep. We have 98% coverage and 80% of all conditionals. We do some typing but it doesn't help that the tools are kinda garbage for typing in python.

[-]

ben_sphynx@reddit

I think rightly, it is that 'lack of typing hides problems'.

runMyCode();
assert(true);

[-]

dweezil22@reddit

I was a consultant at the time, I got my billable hours towards bonus and a morbid amusement, no hard feelings from me.

[-]

double-you@reddit

I see a lot tests that are not well written or documented and so updating those can be difficult.

It should be clear from the test what part of it is the actual test and what it is testing and why do they consider the result they are getting correct. I'd also prefer explanations of why things were chosen to be what they are, like how long the test runs, buffer sizes, ... why the numbers are what they are. "some random number" is acceptable since it tells you that it wasn't a critical part of the test (at least at that time).

As well as documenting the reason why a test was disabled: what broke it, why can't it be fixed, etc.

[-]

ProtoJazz@reddit

Yeah, I've seen an aweful lot of tests that really really really care about shit like order items are in a list, or that a function is called with x, y and z params specifically

But they never actually test that the work being done by the code is what they want.

I actually got bitten by something similar not long ago. I'd written significant change to something. Basically when something got updated in the warehouse, instead of just updating and saving, it went through a process of validation and logging the changes so that it could be followed up later. Who changed what and why basically.

And I added new tests for the new functionality, but there were a lot of existing tests too.

Everything passed, thought it would be fine. But a couple days later we realized nothing was updating. I'd fucked up, and accidentally removed a condition. So instead of "if someone tries to do this specific type of update, regect it, put it in this state"

And instead just always put it in that state every single time.

I couldn't belive it. How were all these tests passing?

Turns out, we had a ton of tests. Not a single one of them actually verified the core functionality of "When I update this item, the item gets updated"

[-]

dweezil22@reddit

Agreed, a test with good docs can be the best real-world docs of all. My one complaint for the system I work on now is that many of the thousands of tests are fairly undocumented, so it's unnecessarily hard to find the exact right test that you want to explore how the system works or start a new feature.

[-]

aonghasan@reddit

you changed the behavior of a function without updating the test.

I’ve heard this excuse many times, and in practice it’s rare.

What is more common is management failing to drive testing as being important. The places where I’ve worked with great testing, were the places that C-level management would ask about testing in update meetings. Something goes wrong, and they ask why it didn’t have a test to capture it. They insist we add a test to prevent it happening again.

Management has a huge effect on pushing culture. When we don’t have people pushing for testing, it’s fine to let it slide.

[-]

break_card@reddit

The #1 reason I’ve seen is sheer laziness because they don’t want to figure out how to setup the dev environment

[-]

Ksevio@reddit

That's often an indication the process to setup a dev environment is too complicated. If you make it easy to test stuff then stuff will get tested more

[-]

moseeds@reddit

Disagree about it being management. In my experience nearly always developers, especially those lacking experience, just don't consider testing as development.

As a result they then compartmentalise development into 'actual development coding' and 'testing' as if they're divisible activities. This then leads to really poor time estimation and planning. Over time it becomes a habit and therefore culture. Which is then taken by that very same person into their management years.

[-]

chrisza4@reddit

It is a little bit more complicated than that.

I have found myself working quicker than many devs around who do not write test 90% of the times. So the issue of “not having time” is not really true. You usually move quicker on average when you write tests.

From my experience, the common problems are

management don’t give people time to get pass the automated test learning curve. Things will get slow for a while but then significantly faster.
Dev usually said at a standup that “I need to fix test”, make it like the test suite become blocker but in reality around half of “I need to fix test” is dev actually break something they don’t aware of. So it’s more like “my code is not ready because I haven’t handle some edge cases I did not aware (and test tell me this)” and not “my work is done I just need to fix test”.

[-]

stahorn@reddit

This times a 100 when you have to maintain old code that you wrote. The amount of time I've saved over the years because one of my old tests reminded me about some strange edge case is huge. This of course carries over with an incredible amount of time and money saved by our customers, as if I hadn't had the test, they would have gotten this bug in production.

At times it's very hard (and quite boring) work to keep tests working. It's tempting to just "go fast" by skipping on the tests. Luckily for me, I have already tried to "go fast" many years ago, and I remember that it only took a few weeks until I regretted the decision. Now I just "work slowly" and progress much faster.

[-]

ProtoJazz@reddit

Something my grandmother used to always say when I was a kid, I've thought really applies well to testing.

As a kid Id frequently rush through things, and do a shitty job. Homework, housework, that kind of stuff. My grandmother would insist I go back and do it right. And she would frequently say "If you don't have time to it right the first time, you sure as hell don't have time to do it twice"

Which as a kid I always just interpreted as "OK, then I guess I just won't do it at all" so maybe not as applicable in all situations.

[-]

yegor3219@reddit

management not giving time to do so

Lmao I was coming in to write more or less this comment. "Write tests? Sorry do I have time for that?"

[-]

SoFarFromHome@reddit

I worked at a company where:

The head of engineering told me that we don't write comments or documentation because the code should be so clear it's unneeded
When I insisted the team write tests, my manager told me I should pilot it by writing tests for everyone, and then given a negative performance rating for being too slow at deploying features.

The only solution there was to find a new job and quit, which is what I did. My new company doesn't write tests, either, but at least they're proactive at identifying and fixing crashes and bugs.

[-]

BobSacamano47@reddit

You don't ask your managers for permission to write tests.

[-]

debugging_scribe@reddit

It should be considered part of the code you MUST write.

[-]

SoFarFromHome@reddit

I worked at a company where:

The head of engineering told me that we don't write comments or documentation because the code should be so clear it's unneeded
When I insisted the team write tests, my manager told me I should pilot it by writing tests for everyone, and then given a negative performance rating for being too slow at deploying features.

The only solution there was to find a new job and quit, which is what I did. My new company doesn't write tests, either, but at least they're proactive at identifying and fixing crashes and bugs.

[-]

MyTwistedPen@reddit

Agree, you are the expert, not the manager. You know what is required to do the job.

[-]

MyTwistedPen@reddit

Agree, you are the expert, not the manager.

[-]

-grok@reddit

Yep, devs can't fix bad management.

[-]

luckymethod@reddit

Like bad management is the cause of bad developers. Sure there's definitely bad management but lazy developers are EVERYWHERE. Let's not pretend people that code are some kind of superior race.

[-]

-grok@reddit

Like bad management is the cause of bad developers.

Well....bad management technically is the cause. Management does the hiring and firing at every place I've worked.

Show me weak sauce engineering management, and dollars to donuts I'll find an organization full of weak sauce engineers.

[-]

rusmo@reddit

Devs can provide estimates thst include time to write tests.

[-]

-grok@reddit

And the business can stop pre-selecting deadlines that don't have room for estimates that include time to write tests.

The truth is that a minority of developers work under management that is appropriate for software creation. This results chronic under resourcing of development work, industry wide.

[-]

FlyingRhenquest@reddit

Include it in the estimate. Inadequate testing turns development into a fire department, constantly putting out fires and not having time for anything else. Some developers seem to prefer the constant stream of emergencies they can point to as things they addressed while doing no work on the company's current goals. They can "fix" the same thing a couple dozen times, frequently without addressing root causes, and that's a lot easier than designing something new. Especially with "this company's shitty tech stack."

[-]

campbellm@reddit

And the managers who insisted on it have failed up and bear zero responsibility for the shit-show that inevitably follows.

[-]

FoxyWheels@reddit

It usually comes from upper management directly above in the same vertical (director or VP). Then they pressure the hell out of lower management, who are easily replaced and just want to hit targets to get their bonus, and finally falls on dev’s heads.

HoratioWobble@reddit

I work in an overall team of 140, distributed globally, working across 232 repos on a product that processes billions of transactions a day. We have about 80% coverage.

The company is so renowned for how shit it is, it was part one of the biggest scandals in my country spanning 30 years.

I got a ticket this morning, 2 hours later I was being badgered for a status update.

I still wrote tests and we have still E2E tests, written in Playwright in the individual code bases.

dimitriettr@reddit

That's the main reason.

People tend to patch the existing code just to fix the issue, and do not have time to understand the whole use case.
When a test fails, it is either poorly patched, or just disabled/deleted.

Repeat this process with a few different people and you end up with garbage tests, or no tests at all.

[-]

ck108860@reddit

expect(someFunction).toBeCalled()

Cypress is the absolute bees knees. We use it for api and UI testing at this point instead of involving another framework.

[-]

ck108860@reddit

I work at AWS and we test everything. I’ve heard this argument before and I agree with it to a point, it doesn’t work at AWS because we couldn’t care less about our actual UI, services need constant tests (canaries) regardless of UI so we potentially can know when services are failing before customers do.

But at a smaller company that does most of their transactions through their UI - write unit tests for thing that are easy to unit test (e.g. regex validation does what you expect it to), then e2e test the heck out of your UI and call it a day.

[-]

oorza@reddit

If your product's primary interface is an API, that's its "UI" as far as this discussion is concerned - it's how your software is interfaced with by its users. For a REST service, for example, an end-to-end test suite should just be a series of API requests it makes - that's functionally the same thing as Selenium clicking elements on a webpage.

[-]

WhoLetThatSinkIn@reddit

Did we just become best friends?

I argued with our QA team for WEEKS that they should be validating api results only via json schemas because we don't make the data.

Shockingly tests are flaky because they still validate data five years later.

[-]

ck108860@reddit

I’m currently on a team that’s obsessed with code coverage in unit tests.

I keep seeing the tests we wrote and I cannot see how people think they are really useful. Specifically comparing the effort it takes to write them and how often they interfere with a code push or at least make it painfully slow. (Because yes, we have a pre-push hook running all tests)

[-]

lunacraz@reddit

why would you run the whole suite? run tests on files you touched, beyond that, leave the test suite on CI

Agreed, but that untestable code isn’t always the engineer who is tasked with writing tests’ fault

[-]

Naouak@reddit

are not good at writing tests

We usually say it like writing test is complicated. It's not. What is complicated, is writing code that can be tested. It asks of developpers to write in a way to make the code less coupled and coupling is usually a way to go really fast. It also asks of the developper to learn to break down what they are doing in logical steps which is harder if you don't take the time to think through what you are doing.

[-]

ck108860@reddit

Totally agree. a lot of new devs will also ask questions like “what do I test” because things are overwhelmingly not testable at first glance

[-]

TheOriginalSmileyMan@reddit

And the ones that are proud of it

[-]

jcddcjjcd@reddit

I developed android apps for 13 years without a singe unit test.

I did however vigorously test on real devices and identified bugs that way.

It worked for me.

[-]

WenYuGe@reddit (OP)

That's incredible! Do you work solo or in a team? What type of apps?

I'm genuinely interested in exploring if the 100% test coverage goal is like the book clean code, and should be taken with massive grains of salt.

[-]

deeringc@reddit

100% test coverage is a foolish requirement IMO. In any codebase there's ~20% of code that has very little value being tested and gets increasingly difficult to test. I don't think that coverage should be a score to achieve. Rather, it's a tool to spot testing gaps and trends over time.

[-]

GMNightmare@reddit

It's the correct requirement. You test all the code you write, period, simple. No more threshold games.

The \~20% of code you don't want to test is exactly the code you need to test. Not only is it the worst written code (hence why you struggle to test it), it's often where all the bugs hide (for largely the same reason).

Requiring 100% coverage does a few things.
1) Proves all the code is testable.
2) Every developer then has to write tests for all the code they write. Simple rule. Nobody is writing tests for somebody else's code, like:
3) Prevents the common occurrence of trying to make a simple change, such as a hard-coded value in a method, and then having to write tests for the whole class because the previous developer skipped tests for it by writing enough tests elsewhere. This is a constant problem whenever I've in a threshold team.
4) Ensures you always get the value of highly tested code, instead of only if you're working on the part with tests.

The only arguments against it generally amounts to, "I'm bad at testing and don't want to." Like, people are outing themselves here.

[-]

sards3@reddit

The only arguments against it generally amounts to, "I'm bad at testing and don't want to."

The actual argument against it is that it takes a lot more time and effort, while providing not much marginal value in return. The goal of your project is to deliver some working software, not to deliver a quality test suite.

[-]

GMNightmare@reddit

it takes a lot more time and effort

Yes, that's the, "I'm bad at testing and don't want to" part. No, it really doesn't. Not when you start out with 100% coverage and simply maintain 100% coverage.

People who only have threshold goals are often confused because they keep running into having to write tests for code they haven't developed due to changes tipping a threshold, which is a huge drag on time and requires a lot of effort as it's code they didn't write.

If you're writing code that takes a lot of time and effort to fully test, you're writing bad code.

while providing not much marginal value in return

Patently false. It's an excuse by people who largely never worked on such a project. Value gains are huge. As I just outlined. Even just by the process alone. No more arbitrary thresholds, no surprises over coverage drops, no more excuses: If you write the code you test it.

[-]

sards3@reddit

Value gains are huge. [...] No more arbitrary thresholds, no surprises over coverage drops, no more excuses

I was referring to value gains for delivering working software products, not value gains for your testing process. It seems like you are saying that a requirement of 100% test coverage is better than an arbitrary requirement of 80% or whatever. Maybe, but they are both bad.

[-]

GMNightmare@reddit

I did not list only value gains to testing process. I listed value gains to delivering working software products. Nothing I said specifically said for tests.

Improvements to workflow are value gains in delivering working software products, since development is iterative.

My initial claim remains true: The only arguments against it generally amounts to, "I'm bad at testing and don't want to." Like, people are outing themselves here.

You have not made any statements otherwise. In fact, you didn't even try this last post. You just claimed 100% coverage is bad at this point. No, it's not. Developers who don't test there code are bad. Skill issue. Problem exists between chair and monitor.

[-]

psycoee@reddit

I work in a regulated field. Let's just say none of the companies I worked for had 100% unit test coverage. Some had no unit tests whatsoever. Sometimes unit tests are a good idea, other times they are impossible or meaningless. For example, driver or kernel code is extremely difficult to test with unit tests. Your test harness would have to replicate the behavior of the actual hardware in some sort of emulator, and most bugs occur precisely because the programmer doesn't precisely understand the hardware behavior in corner cases. A much better option is hardware-in-the-loop tests where you run the code on actual hardware and test it by feeding it simulated inputs.

Unit tests make the most sense for things like self-contained algorithms. It makes sense to test algorithms, and the tests are meaningful and document the behavior. It makes sense to unit test blocks that have complex logic. On the other hand, it's not useful to have tests that are just mirror images of the code. You have to use engineering judgement.

Unit tests don't really work for complex systems where most bugs are related to concurrency and interactions between modules or external factors (hardware, networks, etc). And having a large suite of unit-level tests can easily double the amount of code that needs to be changed if something is being refactored. The optimum is almost never 0% or 100% test coverage. You want unit tests for stuff that benefits from unit tests, and other types of tests elsewhere.

For example, if you are designing an ECU for a car, you probably want to put it in a test harness with a simulator of an engine and exercise it through various operating conditions. Unit testing might make sense for a number of modules, such as the communications stack or e.g. the real-time scheduler. However, it's not sufficient on its own and in many cases is not terribly useful (e.g. if it's code that isn't expected to change after it's debugged and thoroughly tested).

[-]

Sage2050@reddit

A much better option is hardware-in-the-loop tests where you run the code on actual hardware and test it by feeding it simulated inputs.

I work in hardware which sometimes means embedded systems and this is how we do all our testing, unit tests confuse me as a concept.

[-]

FredeJ@reddit

I agree. Everyone’s preaching unit tests everywhere and the example is something like apostrophes in forms.

And I’m sitting here thinking about how to unit test this driver. I can’t mock the hardware - 80% of the development is figuring out how the hardware works in the first place.

[-]

JustinsWorking@reddit

Its because they’re all web developers ;)

[-]

billie_parker@reddit

You could mock the hardware, but I acknowledge maybe the tooling available is insufficient and makes things more effort than they're worth

[-]

WenYuGe@reddit (OP)

This is end-to-end testing, which is still testing IMO. I think this is perfectly fine/valid

jdrobertso@reddit

Considering that you say things like "...an app I wrote them..." and "...my websites", I'm going to guess that you are writing code in projects on your own, without a team who has to understand and maintain your code. You are then, it sounds like, passing off a "complete" piece of software with no expectation of maintenance.

In general, when people are talking about code that needs tests, they're talking about code being maintained by teams of 5-20 people, where multiple people are contributing daily and upgrading functionality basically constantly. I'm currently working on a super complicated piece of code that has been hand-developed over the years by one person, so it has no tests, no documentation, and none of it makes sense to anyone but this guy who left the company. When I make a change in section A of the code, and my teammate makes a change in section B of the code, we might accidentally step on each other's changes when the user clicks a button on page C, that neither of us has touched.

In the world of software development where you're working on a team, developing something that others are going to maintain, tests are absolutely critical. When you're making a Wordpress site for a mom and pop t-shirt printing shop? Sure, skip the tests.

[-]

LetheSystem@reddit

Generally I work alone, but have run teams of 12-15 for maybe four years, a handful of smaller teams, some colocated, some dispersed (California, UK, India, Malaysia). Applications of many millions of lines of code (for lack of a better measure). Running inside three biotech companies. Running the financial portion of the custom ERP of the largest ship management company in the world. Running robotic test systems.

It's just a different way of doing things. And the argument pisses me off, honestly, because people clutch testing so tightly and don't understand that a different way can also work, and has done for the majority of programming's existence.

I'm sorry your previous coder was idiosyncratic and you can't just throw it away. I've had the luxury of doing so several times. Or that you can't pick their brains, but that often doesn't work well either.

If testing helps you get where you need to be, awesome. I wish there were a better way to reverse engineer the thing than to code and test to see if it's good code, though.

Personally, though, I hope to die before I write a test, get approval for a PR, or can't publish straight to production. At billion dollar companies, who frankly don't care about any of those things.

[-]

adobeblack@reddit

You can qualify yourself however you want based off your YoE and team size, that doesn't change how stupid your position is.

[-]

LetheSystem@reddit

Calling someone stupid isn't a really good way to argue. Whatever.

[-]

schmuelio@reddit

I think your justification needs a lot more than functionally saying "I don't need it and I'm qualified to say that".

Your process is (self-admittedly) pushing untested code directly into production with no oversight, I don't know why you're surprised that "trust me it's fine" isn't enough for some people.

[-]

LetheSystem@reddit

Yes, there's much more to be said on this whole topic. Reddit isn't the place for that discussion, and I'm frankly sorry I said anything here, as I alluded to with my original comment.

As to "untested" - I don't believe I said that. I mentioned test harnesses if needed. One's own manual tests and debugging. I didn't mention designing the entire pattern of my application to fit into a testing methodology, no. That I didn't.

As to, "I'm qualified to say that," my presenting applications and credentials was in response to the person who attacked my qualifications by saying that I was building wordpress sites for mom and pop t-shirt printing shops. True, that was an appeal to authority on my part, and not good argument methodology.

I think it's fair to say, though, that there are different ways of going about the whole software development process than the test methodology currently en vogue. Pointing that out should be a reasonable thing to do, and shouldn't be met with pejoratives and attacks.

Plenty of large companies don't have stage / test and push straight to production, by the way, for whatever reason of their architecture, practices, etc. They have processes to make it work, not all of which involve automated testing.

I'm not surprised that some people can't get by without tests - it's how they've been taught, and how they work. It is not the only way, however. Other ways are just as successful, if not more, depending on the task and the players.

So, "trust me it's fine" isn't something I believe I've said, and I'm not surprised at the responses here.

[-]

schmuelio@reddit

I don't think anyone is saying "not testing" doesn't happen, they're saying it's a bad practice.

As to "untested" - I don't believe I said that.

You said multiple times that you don't write tests. Including saying that you hope to die before you have to write a test.

Test harnesses aren't tests, they're frameworks for writing tests in. A test harness is usually a good idea for large software but it's by no means a requirement for having tests.

Being generous, there are three ways to read your comments so far:

You do test your code, you just don't consider them tests because they're not written in a framework.
You test your code by doing one-off passes of your applications to check they look like they're doing the right thing. This is better than nothing but again, you haven't really explained why that's better than doing repeatable tests.
You don't test your code, in which case it is untested.

Listing your qualifications are about the closest thing to justifying your position you've provided. I can ignore them if you don't think they're relevant but it leaves you with even fewer stated justifications for thinking that way.

So, "trust me it's fine" isn't something I believe I've said

You didn't say it, but when you provide no reasons for thinking the way you do, then you are just asking people to trust you when you say it's fine.

Finally, to address the sort of underlying bits of what you said. I think you're severely missing the point here. Having bad practices be common and accepted things in industry doesn't make them good practices, and saying they're common and accepted isn't a justification for not pushing to improve those practices.

The reason why writing repeatable tests for your software is a good practice (compared to just not doing that) is that human beings make mistakes, they fail to consider every use case, and generally miss things. Tests provide an extra layer of checks to reduce the likelihood that those mistakes make it into the final product.

That doesn't mean that all tests are always better than no tests, tests are subject to the same mistakes and oversights that code is, but they do introduce an additional place where something has to go wrong for a mistake to make it into the final product.

Not pushing directly to production is an extension of that reasoning, it adds more places where something has to go wrong for a mistake to propagate through.

Also, this bit:

They have processes to make it work, not all of which involve automated testing.

So this was interesting, because those "processes" to "make it work" almost always involve human beings manually checking that everything works as expected. This is testing, it's just explicitly less efficient and less effective than doing the same thing but automatically.

The reason why it's interesting is it sort of implies that you don't consider manual testing to be testing. Which implies that you do test things, you just don't want to have the computer do it for you.

[-]

LetheSystem@reddit

When I said that Reddit wasn't the place for the discussion, that was to say that the discussion is far more involved than comments, on a phone (made it to a computer now, whee!), where nuance is basically absent.

I believe "testing" in this discussion to mean "automated testing" rather than something performed by the developer - to mean tests which run as part of the check-in process, or what have you. I do not write automated testing, and do not work with teams which do, for one because I believe that they add less than they cost.

I'm not attempting to ignore my academic qualifications - I'm saying that I agree, my academic qualifications should not necessarily lend that much weight to my arguments, as they simply indicate that I got an education. I may feel differently, but I also have a degree in analytic philosophy (logic), which means that I understand that the logical argument of leaning on my degrees is flawed. I will certainly not ignore my professional achievements, however, which do include significant applications and leadership.

I'm not asking that anyone trust me. I would, however, like for people to consider the alternatives to automated testing. I'm sure I've represented that poorly in the comments.

As you point out, there are opportunities for failure all through the development process. I merely point out that slavish devotion to automated testing will not solve those failures, there are alternatives to that methodology, and that those alternatives are routinely ignored.

As to manual testing being less efficient and less effective, I'm sure there are metrics. I'm also sure that I can offer anecdotal evidence to the contrary of those metrics. Do I believe my experience over someone else's study? Yes, actually, because those metrics do not meet my experience.

I guess I would say: "having the computer do it for me" is an interesting concept, when building your own app, to test what needs testing / debugging, is actually having the computer do it for me. I'm just not trying to go for code coverage, or something like that, and not building my whole application around testing (e.g. via dependency injection). I'm saying that what I do is what I would consider debugging, rather than testing - it's the developer, working out the kinks. If they're good enough, enough kinks get worked out that it's a functional application. That's not to challenge someone's skills, but to say that it's a methodology you get used to & you get good at doing the work, or at recognizing where there's a problem. Test-centered programming... at the very least, it's not for me, I guess let's say.

[-]

schmuelio@reddit

To bring it to a close, I'll note that you haven't really explained what your process is (or why it's better, but at the very least what it is would be good).

You've mentioned several times that there are alternatives, but I think it's noteworthy that you haven't actually detailed what those alternatives are. Let alone why they are preferable or what benefits they offer.

[-]

LetheSystem@reddit

What I do on a project?

Write a custom CASE tools to avoid lots of the bugs.
Debug the logic to make sure it works (maybe using a test harness).
Exercise the application / feature in its finished state.
Deploy.

I may spend longer working on the CASE tool than I do on the code I generate with it, and longer on that logic than anything else. The CASE tool generates the application pattern I want to generate, and if done well then I don't have manual edits to the code when I'm done.

In terms of the benefits: by the time I'm done with the CASE tool, I (should) completely understand the application I'm building. It's probably fair to say that I'm "testing" when I'm working on that tool - iteratively working out the code in aggregate or something.

As to why it's better. I once rewrote 2 years of a guy's work, in 2 weeks. It was just a pattern and he was hand-crafting it, we were stalled, it had bugs. I was tired of waiting (and young and cocky) and designed a CASE tool. Now his code wasn't buggy and we could get on with things.

I have a full career of applications behind me, quite a few of which are still running and have been for decades. In terms of benefit, there is another. My applications have generally lasted decades (and no, they're not trivial).

It's not much of a process, you'll say. Maybe. But I'll (tongue-in-cheek) quote Don Knuth to say it's the Art of Computer Science.

[-]

schmuelio@reddit

You write a custom CASE tool per project?

That seems unnecessary, CASE is meant to be general purpose. Although I suppose there's a spectrum between DSL and CASE. If you're reusing CASE tooling (which you sort of should be since the main benefit is that they're reusable) then you probably should be testing it since the code base for that tool will change over time as you need new stuff adding to it.

Either way from the sounds of things it seems like you don't do much code maintenance if that's your general process. Picking up a piece of legacy code and working with it (the vast majority of software and tooling companies) is a whole other ball game. Given how you're talking I'm guessing you're a contractor who's brought on to projects to write new software? If so I wouldn't say that's generally applicable to most dev careers.

[-]

LetheSystem@reddit

You're correct, I do reuse, and maintain those case tools as part of each codebase - they're left with the client and I'll upgrade them as opportunity allows. I'll blow away thousands of lines rather than edit one - doing a diff to be safe, etc. - so, maintenance preferably looks like that. When it can't, it might be a total pain, and that's possibly where automated testing would be beneficial... if I'd spent the time to create them, of course. With my apps, maintenance tends to be very seldom*, so I really don't think I could justify it.

Everything I've ever written has been my database and only one hasn't been my complete architecture. All greenfield development, all database centered**.

When I'm confronted with legacy code, it's to rewrite it. That means dissection and a brand new application. Which may mean writing an application to understand the legacy app, and that'll be more ad-hoc, tearing at the app, data, code.

And yes, contractor has been probably 2/3 of my career. Brought in to deliver a whole application, start to finish, from requirements gathering to team formation / hiring. Sometimes project management formally, sometimes more architect / team lead. Quite often solo.

I have sensed that what I do is radically different to what a lot of programmers do, how we work. I haven't ever had an opportunity to see how "modern" craft looks. Quite a bit of it sounds quite anathema, as in sure I've expressed.

I have two still running I wrote in 1998/99. I hope to rewrite them this year. Server upgrades I don't think count as maintenance here. I have a handful of others running, older than 10.

**Marketplace competition algorithms, demand planning, complex invoicing. Things running biotech processes, applications running on about 1,000 container ships. Databases running inside medical instruments. Pieces of a custom ERP running in over 100 countries.

[-]

schmuelio@reddit

To put it bluntly it seems anathema to you because you pretty much only write new tooling and applications that adhere to your design.

In "modern" (automated testing isn't new, Jenkins is 13 years old and I'm sure it wasn't the first of its kind) enterprise software development that rarely happens.

Also to be blunt, the examples you've provided are mostly not things that companies would bother maintaining, embedded software usually is left alone (I would count the container ship application as embedded), ERP would very likely get replaced rather than updated, biotech is full of legacy code (of which your applications would be one), and so on.

Most developers work for a company that produces (for internal use or for sale) one or more complex tools that they didn't write. That necessitates at least dozens of hands working on it over the course of years. By "complex tools" I mean things like Visual Studio, Outlook, compilers, document editors, analysis software, website frameworks, virtualization platforms, operating systems, design tools (like CAD), etc. These things have massive and wide-reaching use cases and get used by a ton of (usually untrained) people, and need to work anyway.

[-]

LetheSystem@reddit

I do not disagree. Totally different work, theirs and mine. There's a lack of knowledge about the other on both sides, and some looking down. Different development and application lifecycles.

Personally, though, I hope to die before I write a test, get approval for a PR, or can't publish straight to production.

This is a terrible position to hold. Pushing your changes - untested - straight to production, with no oversight?

That's a recipe for disaster, and relies basically entirely on the assumption that you never make a mistake or overlook anything.

[-]

billie_parker@reddit

I hold a master's in information systems, master's in analytic philosophy, and a PhD in computer science

You realize that works against you, right?

[-]

LetheSystem@reddit

That I've studied, extensively, in the field? And don't believe that automated testing is worth doing?

[-]

billie_parker@reddit

The stereotype is that academics don't know how to program

[-]

LetheSystem@reddit

Ahh. Hadn't even seen that, thanks.

There's too little space / time in here to really give a coherent argument, or picture of oneself, one's skills, one's experience.

That I started on education after about 8 years of experience, because I wanted to become better at it.

Or that I wrote a medical records and billing system when I was 12, and upgraded it a few times until them buying off-the-shelf when I was about 30.

It's annoying, not to give the full picture. It's worse than Covid WFH.

[-]

praesentibus@reddit

tf m8

[-]

WenYuGe@reddit (OP)

same. no disrespect. genuinely surprised this sentiment exists and would love to hold a conversation about why this is the though process.

[-]

LetheSystem@reddit

"same" to whom, please? And which sentiment / thought process?

[-]

WenYuGe@reddit (OP)

To your experience and sentiment toward testing. I genuinely am curious how ensure anything you write works and continues to work. I write tests mostly to convince myself that these things are working somewhat according to my expectations.

I'm curious about the other approaches and thought processes :D

[-]

LetheSystem@reddit

Well, this kind of formalized testing came about when I was ten years into this, for one thing. At that time, you created a test project and ran tests manually, and it was a whole lot of work for little reward, for what any of us (at HP) could tell. So we didn't look at it again.

We'd build a test harness - an app, usually console, with a bunch of methods we could use to exercise the functions we wanted to debug. In other places, we'd put in logging. And that's about it, really. Build a test harness if debugging it isn't possible in the ide. Otherwise, it's all down to debug skill.

Don't get me wrong: the things I put out have been tested, but by me or my team, knowing what we've written. Are there bugs that hit production? Yep. There always will be. I kinda justify it by saying we make progress. But really it's 'cause it's not life critical.

Yes, I'm a fossil.

It's simple really. Code written defensively, that allows business logic implementation is build upon trusted invariants, thoroughly manually tested on all supported scenario plus some extra steps on data space, only modified in a way that respects invariant or clearly defines new one will live a great life.

Basically, automated testing works as a safe net for people that don't care enough of invariant either in the definition or respecting them. Automated test or not, the only way to have a solid codebase is to have it predictable when you do changes.

You probably had case where you exactly knew what tests needed change after a code edit, even maybe updated it properly before even running them, so everything was always green. Well, with the proper mind set and code base, you can work that way 100% of the time, and manually test the code paths impacted by your change.

[-]

Swamplord42@reddit

I wrote a test. Once. 20 years ago. Decided it gained me nothing that a manual test harness wouldn't.

That's why people don't want to hire old developers. No one wants someone that tried something once 20 years ago, decided that was enough to have an opinion and won't budge from it even though it goes against industry best practice.

Having the position that tests aren't worth it most of the time is reasonable. Having the position that automated tests are never worth it isn't. Not even re-evaluating whether this position makes sense periodically is insanely closed minded.

[-]

LetheSystem@reddit

Didn't say I hadn't kept up with changes in the world. Didn't say they were never worth it. Didn't say I hadn't reevaluated them. Said it was a different kind of development. Jeez, read, don't read into.

People don't want to hire "old" developers because of a variety of reasons, ageism is one, cost is another.

[-]

BigHandLittleSlap@reddit

Looking at your comment history, it seems you use mostly PHP and JavaScript.

Yeah, those would be madness to use without automated tests.

In the world of strongly typed languages like ASP.NET (C#), the value of tests is a lot lower because the type system does many of the same checks implicitly at build time.

Something you would need a unit test to discover in JS the compiler will simply report as an error in C#.

[-]

FullPoet@reddit

Honestly feel that from your comment you dont understand why you need automated testing or have never built anything bigger than a toy project or basic CRUD software (where most of the time you could easily get away with no real backend).

The type system does not and cannot protect your application from producing data that is can be considered invalid from a business perspective and valid from a type perspective.

[-]

BigHandLittleSlap@reddit

Oh.. let me guess: you’re a user of MySQL too?

I use SQL Server and encode these rules into constraints I can trust to be enforced by the database engine.

[-]

FullPoet@reddit

What are you smoking? That isnt what you wrote, you said the dotnet type system. Not db constraints.

Like I said that works for basic crud applications. While sure its possible to write dB constraints for business rules, but why would you? Splitting up business rules into both the dotnet application (and whatever) db engine you're using is insane and prone to tons of errors.

Can't mention how many times ive had to dig out edge case business rules that weren't documented at all but were implemented as db constraints, triggers, views, etc.

I would guess around 1% of companies are doing tests with more than 80% code coverage which is also at least somewhat part of the workflow. This could be CI/CD or at least part of a code review or some such.

I'm not even including two bit companies building wordpress restaurant sites. I'm talking people who make medical stuff, train (rail) stuff, oil & gas stuff, utility stuff, etc. By stuff I mean software and hardware with embedded code.

These are systems where billions are lost, people die, and ecological disasters happen if something goes wrong.

Yet, the people doing these things will often claim what they do is "rigorous". Yet, a careful examination of their rigour will turn out it is "rigorous" because it is done by electrical engineers who have a PEng. Or they will claim they have a "rigorous" code review process, yet it doesn't look at unit tests, integration tests, or even a static code analysis; just looks at code style, comment style, file naming, etc.

Often in these high value systems they will have manual testing. Except they are often very complex spaghetti architecture systems where code in one spot can affect functionality almost anywhere, thus a manual test focusing on the changes could easily miss the fact that some other critical functionality has entirely crapped the bed.

Here's my own personal experience with testing: Once my system has become even mildly complex I like my tests. They often find weird little bugs; my tests tend to beat up the code pretty hard. Insane inputs, zillions of attempts, null objects, the lot. When a bug is found outside of a test, a test is then created to exercise the bug. Then, this test starts passing when the bug is eliminated. Regression is monitored through the tests.

The code is also cleaner with the knowledge that I have to make it easy to build a test. More modular, less spaghetti architecture, cleaner API.

The tests are fantastic tutorials on how to use the API, but the unit tests are a great tutorial on how to use the functions within. Often the tests are all about some constraint or requirement. The test will be: System must allow for 1000 simultaneous logins per second; this test pushes this to 10,000 per second.

Timing the tests is great as it can reveal bottlenecks, or new slow crappy code. This last is often a sorta bug. New code might not be killer slow, but now some GUI which was super snappy is now taking 100ms. This is both a waste of compute time, but also means other similar slowdowns might make for a terrible GUI; so fix it now.

But what all this means is that new code is sitting on top of a clean well tested foundation. I will spend very little time fussing with the rest of the system trying to get my new functionality to work. This means my time is spent working on the actual problem, not fighting the crummy tech debt codebase.

This is no small thing. Tech debt of this sort is what grinds productivity to a halt. Features which should take hours are now taking weeks. Weeks of trying not to break a large complex fragile system.

There's a book on legacy systems which goes something like, it doesnt matter if you use DRY, PIMPLE, OOP, or any of the best practices in software development, if you aren't writing tests, you are writing bad code.

The usual attack I see on unit tests is that they don't guarantee good code. Absolutely true. But, no tests do guarantee bad code.

[-]

headhunglow@reddit

Yup. I wouldn't even know where to start testing PLC code... Where I work all the safety stuff is relegated to minimal safety PLC:s or hardwired, so the PLC programmers can mostly ignore it. Still, a bug in a PLC can (and has) cost our customers millions.

[-]

LessonStudio@reddit

I would suggest some kind of external io simulator. At least this could exercise piles of inputs and check against desired outputs.

Then fuzzing where nutty inputs shouldn't bork the PLC.

[-]

WenYuGe@reddit (OP)

I feel like I've no idea where those devs are. I've been at hip startups or tech focused companies all my short career. I am genuinely surprised to hear these numbers.

It may vary per industry. 90% of devs not writing tests is absolutely not my experience in my almost 20 years writing professional software.

[-]

psycoee@reddit

What usually ends up happening is these medical device companies started out as 10-person startups with 1 or 2 extremely talented software developers doing everything. They are already working 80 hour weeks, so they are not going to write tests if they don't have to. That caliber of programmers can often write relatively bug-free code, especially since they are doing it from scratch, there are only two of them, and they are probably sitting next to each other. Eventually, the 10 person startup becomes a 10,000 employee company with a multi-MLOC codebase that traces its roots directly to the code written by those two guys. And since they were in survival mode that whole time, they were building functionality, not writing tests. At this point, the code works, the customers are relatively happy, and at this point it's hard to justify a $100M+ investment in writing tests for code that basically already works well enough.

Usually, this attitude changes only when you have a Crowdstrike-scale clusterfuck. But by then, the company is probably in maintenance mode and nobody is adding any functionality anyway.

[-]

cosmic_chef@reddit

Idk about these numbers, but I know my team is that 1% because of our culture. Full CI/CD for merges to main and when we tag. Security checks for hardcoded secrets, unit test code analysis that won’t let you merge under 85% new line coverage, test container builds, and when we do merge we perform automated e2e testing where we act like the user. Verify all inputs provide expected outputs. If that fails, we can’t promote anything to higher environments. Any stories we have, our definition of done includes unit testing.

Does this suck sometimes? Ya. But if you’re really feeling lazy you can typically get 80-90% of the way there with copilot. Just ask it to give you unit test cases for a particular class and you’re off refining those until you get full coverage.

Don't try to hit 100%. Every codebase is different but that last ~20% adds very little value and gets increasingly harder to achieve. The tests get increasingly contrived just to get some extra piece of coverage but without actually testing something useful. It's during this "hard" and "low value add" phase that people and teams get turned off testing. Test coverage is just a tool, we shouldn't have an absolute target but rather it should be used for ensuring things are trending in the right direction (ie. Not dropping) and for finding test gaps.

[-]

chowderbags@reddit

Realistically the returns are going to be on an S-curve, where having a few crappy tests is pretty worthless overall, getting 80+% coverage is pretty good, and trying to squeeze from 99% to 100% might be a nightmare that will take more effort than its worth.

[-]

shoe788@reddit

A percentage target is the absolute wrong approach. Tests are for reducing risk. You reduce risk until you meet the desired level of risk tolerance. Risk tolerance will be different everywhere. Management cant standardize it depends so they come up with percentage targets they can enforce everybody to obey.

[-]

WenYuGe@reddit (OP)

Love this

[-]

LordoftheSynth@reddit

A properly chosen suite of build verification tests (and I'm talking like 100) for your product should get your coverage numbers above 60%. If it's not, your build verification has some pretty serious test holes.

Hitting 80% with a full functional suite is not hard. Again, if you're not getting there, something

I do agree it is a game of diminishing returns: tasking SDEs or SDETs with writing increasingly specific tests is a waste of resources. You don't need a test to exercise every possible failure condition, for instance.

[-]

SilverCats@reddit

You don't need to test if you have no customers.

If you have customers you always test. Sometimes you test before your customers.

[-]

cdsmith@reddit

This is another one of those best practice articles that forgot to say anything interesting. Do I believe that there are a lot of developers that don't write automated testing? Sure. Does writing an article about it do any good? Not really. The problem here isn't that these developers just haven't been enlightened about the value of testing, nor that they don't have "discipline", whatever that means.

The real problems:

Testing isn't valued by management, and it's tough to ask junior engineers to spend time on something when management just sees a gap of time where they aren't merging changes.
Adding tests into a code base that isn't set up for it really can be a high-effort low-return task, especially if it means you need to figure out CI, which takes high level organizational commitment.

In some cases, as well, the people complaining that others don't test just have a narrow point of view. One project I worked on had a comprehensive set of representative real-world data that we were trying to do the best job on, and an elaborate system set up to monitor for changes in the quality of the result and attribute them to individual code changes. In that context, if you determine that adjusting a system parameter improves performance, you can confidently do it. But we still had the occasional "this is the best practice" types sending changes that would tweak one parameter, and then also write an elaborate test that verified that the system really did use that new number that their commit modified in the config file, sometimes even including refactoring to make the code many times more complex to "improve testability". When asked to remove that monstrosity and trust the system, I have no doubt some of them walked away wondering how we hadn't got the memo that testing is a best practice.

(That's not to say that integration testing makes unit testing unnecessary. Quite the contrary, if you are building abstractions, then it is immensely valuable to test at the level of those abstractions so that you have trustworthy building blocks to build with. But there are too many people for whom "write a test" is a checkbox they tick off without stopping to think why the test has value.)

[-]

I agree that the structural problems you talk about here are also problems.

However, I have worked with plenty of people who say the things this article talks about and believe this is also an individual issue that needs to be addressed at the individual level.

In fact, I think these individual problems feed into the structural problems. I have observed planning meetings that have gone like this:

Developer 1: "That area of the code base hasn't been tested so refactoring it for this feature is going to take longer to ensure nothing is regressed"
Manager: "Ok, are we talking about more than a sprint?"
Developer 2: "Hey, I tested that 4 years ago when I wrote it. It works fine"
Manager: "Oh! sounds like you are worrying about nothing. Can you make sure it is ready for the demo on Tuesday?"

It's not worth fighting for, instead, I'll ask for time to fix the problem later. Same goes for security.

Don't blame the player, blame the game.

This is the agile they want, and I just want to get paid at the end of the day.

[-]

nextstoq@reddit

Same. I've been a dev for over 20 years, most of that in web development. Very rarely is there budget for unit testing. If you're lucky there are QAs who have automatic or at least some sort of structured testing. Bottom line for the client is their bottom line - it's usually better economically for the stuff I work on to get it live with a few bugs than to test it so it's "bug free".

[-]

Maxion@reddit

Exactly, there's 0 business value in a project that goes over budget, or is released late. There can be a lot of business value in buggy software released on time. This is what a lot of managers (And purchasers) have to deal with. Not every company in need of custom software is a 1 billion a year revenue behemot, companies with ~10-20 million a year revenue also need software, but they don't have the margins to pay for more than 1-2 developers. Hence you're always incredibly time constrained.

[-]

jackmans@reddit

there's 0 business value in a project that goes over budget, or is released late.

vs

'how much time and money would be wasted needlessly testing stuff that is unlikely to cause issues'

vs

'how much would the damage cost if it did go wrong'

Then you decide where and when to test. You don't need unit tests for, or to test, everything.

Another thing is to just hire only very senior developers to reduce your risk of issues as they're more likely to get it right first time.

It's complex and nuanced, but it isn't always ignorance or laziness. It's often a business decision.

[-]

Savings_Row_6036@reddit

No tests, no testing, and not even writing the code they commit.

[-]

EvaUnitO2@reddit

This only gets fixed when the business begins to value testing in addition to valuing feature development. Otherwise, testing will always be pushed back down to the engineers as a thing they can do if they want but should not be eating in to the rest of their effort toward new feature development. That's why testing just often just never happens.

It's also why tech debt tends to mount and mount.

[-]

foxcode@reddit

I'm dumbfounded by the number of devs who advocate for 100% test coverage, with no consideration for the current state of a project, or an acknowledgement that tests do not all provide the same value. Context matters.

If a piece of code is handling resource authorization, then that code is more important than most random buttons in your user interface (exception for buttons that fire ze missiles!). Some code is more important than other code, and it's corrrectness matters more for the business, and or developer sanity. Writing tests for that code has more value. This is the value factor.

Now there is the cost factor. Pure functions are generally easy to test. Tools like dependency injection can help you here, but there are limits to how pure your code can be. User interfaces again are an obvious example. You generally have to fake a lot of functionality, using a browser like environment, with many layers of magic to make a real integration test work.

What I'm suggesting is you could plot a graph. Ease of testing against the value of testing, and while I don't suggest actually drawing it out, I think this is a better approach to testing. 100% coverage requirements lead to box ticking, and huge amounts of time spent fighting with layers of magic that get updated far too often.

Two final points.

Using a static strongly typed language can really help. While I don't enjoy typescript, I've found it helpful in large javascript codebases, both for readability and code quality. Where I can, I'm trying to use Rust, as that provides significant levels of safety.

I think there is a third metric, likely subtelty of a bug. An error in some code is likely to lead to far more subtle or nasty consequences than other code. This should be included in the value calculation.

[-]

the_unsender@reddit

As someone who has done lots of contracted development/devops work, I can tell you from experience that clients get PISSED when you bill them a significant amount for automated tests. I mean absolutely livid.

[-]

jackmans@reddit

This is true, clients tend to have strong opinions about how contractors do their job and how they're paid. However, you don't need to bill them for automated tests specifically. Why not just lump it in with development?

[-]

DullBlade0@reddit

Would I like to test? Yes

Do I have projects that could perhaps benefit from it? Yes

But when clients change requirements up to hours before going to prod (I'm not joking here) shit changes way too fast to make that a reality.

And after that I'm not getting paid nor get time allotted toward writing tests so what can I do.

[-]

RevolutionaryYam7044@reddit

so what can I do

Have you ever heard of this interesting little word called "No"?

Simply refuse last-minute changes. It's not possible in that short time frame. End of discussion.

[-]

DullBlade0@reddit

Then the whole thing doesn't work, then the client calls my boss, boss calls my manager, manager calls me, I explain it won't work, a bit of back and forth and in the end I still have to implement that thing because pushing back timelines for the client is a no-go.

[-]

Meh,

If the client wants to deal with downtime and their customers complaining about bugs it's their problem.

Boss/Manager/Me will just bring out the mail where we said they were asking for untested shit to go live and that if they want the fix they can wait the proper time to make one.

[-]

Traveling-Techie@reddit

In my career I’ve worked for about 17 companies that developed software, and only 1 or 2 did software testing.

[-]

ClubChaos@reddit

In my experience unit testing, integration and e2e test are at best a complete waste of time and at worst a mess of creating an unoptimized, normalized for the sake of being normalized codebase that is impossible to extend or modify without rewriting tests.

All so some dev can be like "see? The tests are the documentation and proof of work" with a smug grin.

Testing is useless for 95% of projects and I completely agree with theo's view on it.

[-]

underNover@reddit

Think tests depend on the domain you’re developing in. Mission critical stuff like infrastructure software for law enforcement or interpol, or medical software? I’d just become a whistleblower. CRUD application to lose weight? Can be worth it.

From my experience though, even if it’s mission critical, management will sometimes still abandon such ideas. We only manually test for example, but bugs keep pouring in en masse after each release, even small ones. Hell, even had a case where one of our clients invoiced too much because someone broke the formula again, and it just got silenced to avoid brand damage.

[-]

aefalcon@reddit

Yeah, it's a constant struggle with people I work with. And those same devs usually write code that isn't modular, because writing testable code basically forces you to write modular code.

[-]

keepthepace@reddit

In most of the companies I worked with, we start coding without specs written. We make POCs, prototypes and then only products.

You can't write tests before specs especially when these are changing.

WenYuGe@reddit (OP)

I think outside the active online tech circle when I venture into the wild wild world of local dev shops, banks, and whatnot, their software practices are always surprise me.

I like, don't understand how there are stories of devs not testing. I mean I've also seen companies that keep a running log of changes in files for the last 30 years and require manual formatting of files...

[-]

mrMalloc@reddit

As a consultant I have seen code that “shouldn’t exist in production…..” in business that both got the cash and should have the know how.

I also taked to devs about “unit tests” to be scoffed at why do I need to test my frontend. I can see it works ……

[-]

sojithesoulja@reddit

I don't know how to test because I don't know how to develop properly. I think I'm close... been reading up on software architecture. Specifically, hexagonal + DDD. Google domain driven hexagon for a great github repo with nestjs. The concepts make sense but just require a fuck ton of practice and planning. I'll check this out tomorrow.

Also, fuck Optum. They never trained or taught proper practices.

On that note, maybe someday I'll escape this hell. I made a mistake 2 years ago quitting with only 2.5 years experience and I did so at the top of the tech job market.

[-]

WenYuGe@reddit (OP)

:kek: quality content.

[-]

tangoshukudai@reddit

It is very frustrating when the dev doesn't do any testing, and throw it over to QA with zero verification. I get why you might not create a unit test or UI automation test, but it's unacceptable to not manually test your code.

[-]

kernel_task@reddit

Unit tests have almost no value. Integration tests and end-to-end tests are really difficult to write, especially correctly so they don't fail spuriously. Tests are extra burden on maintenance, so they better be of value. Lastly, even if you write the most beautiful tests in the world, bugs will still get through.

Back when Dinosaurs Roamed The Earth and i was still young and believed in things, I made my code rock solid, tested everything and rarely had any issues at all.

when i'd get a request for a change that would break things, or wa just out of scope, i'd say "no".

And Life was good.

Then Management took over. They didn't' care what was possible or reliable. They cared about what lies they could tell the customer to get more money.

A first I'd say "no" but they just kept coming. So eventually I said "fuck it". Want Pong inside the Wait Cursor for your banking app. Sure IDC. Want the DB accessible on the internet beu h VP like to look at it and doesn't want a VPN? Sure. IDC. As long as I get paid.

All the current BS can be laid directly at the feet of bean counters who transformed software development from an enjoyable Creative process with time to reflect test and re-architect and think" to "how many widgets did you code yesterday sn ho much money did we make last month."

[-]

IntelligentSpite6364@reddit

deadlines dont always have the courtesy of giving you time to do automated tests, work with what you got

[-]

Neoshadow42@reddit

Was in a situation recently where a Senior who hadn't worked on the repo before submitted code - I asked where the tests were and they said "Oh this interacts with an external component so it can't be tested"

"Uh...you need to mock the component?"

"What do you mean, mock the component" is the response I got from a SENIOR software engineer.

I'm not surprised that it's an industry-wide issue because I've been in so many situations where I ask for tests to be written at any level and the response I get is 'But why'

[-]

axilmar@reddit

I hate to break it to you, but:

developers do not 'release' software.
developers are not responsible for test plans.
developers are not requirement testers.

Every development team should have at least:

1 developer (i.e. programmer).
1 requirements engineer.
1 software test engineer.

Yeah, perfect is hard to reach. It's also super scary to touch code in a low-coverage repo in my past experience. I don't know how many things can break when I change one method :kek:

[-]

Worth_Trust_3825@reddit

In my case it was always when I inherited an application that was built in a way that you could only do end to end tests. So you just wouldn't bother.

[-]

goomyman@reddit

“Having unit test being run as part of CI (Continuous Integration) on a system that mimics the specs of the deployment environment is the best way to validate a program…”

Ok I am not a unit test purist (Idon’t care a single test tests several things, or if the tests only touch a single method) you can call the tests anything you want but for the love of god “unit tests” should not have any environmental dependencies. There is no such thing as a unit test that mimics a production environment. There should be no environment.

I am a big fan of metrics in production and continuous synthetic tests against production rather than integration tests - which I find expensive and flaky.

Thousands of fast environment independent tests -> synthetics monitors and metrics in pre production and production environments-> safe fast and reliable automated rollback on errors.

That’s the trifecta IMO.

[-]

somewherearound2023@reddit

"I dont care what you call your tests, as long as you call them before you check your code in"

[-]

safetytrick@reddit

I mostly agree with you, except that I think there is a lot of value in learning how to write tests that aren't flaky. Flaky code happens in and out of tests, I've fixed a lot of flaky tests that were only flaky because the application under test was flaky.

[-]

goomyman@reddit

A test without an environment is rarely flaky

[-]

bramley@reddit

I test anything that does calculations. I was told not to test UI because that will get picked up in QA anyway. This is mostly because writing tests for React UIs gets complicated quickly, AFAICT.

All my other clients have lots of tests written for them. Especially the Ruby ones.

[-]

dethswatch@reddit

Fun, but can we also gripe about how bad the analysis on new items is? One-liners that barely describe what needs to be done? wtf

[-]

Razvedka@reddit

Some in senior technical leadership literally don't believe in testing, and they're bizarrely very proud of that stance. Quite brazen about it.

[-]

donatj@reddit

I work with a dev who regularly submits giant multi thousand line PRs that usually only kind of work. So often I am just yelling at my screen "did you even TRY this code?" and he's clearly peaved that I'm holding his code up to higher levels of scrutiny but it's like start writing some f*cking unit tests and maybe I'll trust it.

[-]

Zanthious@reddit

i found making the devs develop all new code thru unit testing just to save time on test apps and having to use an app to test a function thats 10 button clicks away to be easier than anything else.

This is a 2 way street though, i have had tech support people deal with little annoyances for years before even bringing it up to the dev team who solved it in 3 minutes.

one i got them to code via unit tests my stuff got alot less buggy. *shrug* to each their own i guess.

[-]

drawkbox@reddit

I always test code via unit, integration and system testing. However unit testing can go too far and become a weight.

I am more annoyed by developers that don't test the final output on web, device, desktop than anything.

The project also can determine what is the appropriate level. A product that is years and years in progress should have many tests. A one off project that might last only a short time or a small project it may be completely unnecessary.

The best way to be is setup using interfaces and the ability to test, whether that is needed or not at the unit level as much is up to the project.

However not testing the output and final presentation is just not smart nor good for a product, even one that is ephemeral.

[-]

Neocrasher@reddit

The thing I don't like about testing is how easy it is to write bad tests. A lot of the time when I make changes to our codebase and then fail a test it's not because the functionality is bad or broken but because the test made certain assumptions about how the code would work that aren't true anymore.

[-]

OutsideDangerous6720@reddit

On a strongly typed language, most unit tests have negative value

[-]

fire_in_the_theater@reddit

testing doesn't get bullet points on impact resumes, it's really that simple

[-]

RddtLeapPuts@reddit

If you write tests during your technical interview, I’ll want to hire you right away. I don’t know why candidates never do this. It’s so easy

assert reversed(‘abc’) == ‘cba’

Write 3-4 instances of this. It takes a minute

[-]

omz13@reddit

There was (many years ago) a product demo in front of a client that went quite wrong (promised new functionality caused app to crash when invoked). When asked "did you test your code" the response from the programmer was "it compiled without error". There there followed a 10 minute very profanity-filled lesson in the differences between compile-time and run-time errors. You would have thought this programmer would have learned: nope, did something similarly stupid a few months later.

[-]

GalacticalSurfer@reddit

My co worker can’t even grasp simple typescript. I tried to get him into it and I saw “any” all over the place. Imagine tests. I had to do some changes to a small front end he developed in js a while ago and it was a nightmare. I managed to make it work with the updates, don’t ask me how.

I am in that group. As others said, not knowing how to write good tests and tight deadlines were the main reasons. I don’t have much years of experience but unfortunately a lot of responsibility.

Recently I’ve had to take over a project by an ex employee. Results were not going as expected. Again, what a mess… this time in TS but seemed like he was learning NestJS framework. So back at again fixing other people’s shit, slowly started to implement unit tests where I can. Not always possible because writing tests and mocking a bunch of dependencies is also a pita.

[-]

GalacticalSurfer@reddit

Oh and since this is supposed to be a microservice (you guys watched this movie many times, distributed monolith), some entities are shared. He used a different name for one, and created an exclusively local entity with the same name as the other entity on the other service. Inconsistent relationship property names. It’s gotten me pissed off that I finished what I was doing to tackle this mess and do it correctly. I just changed the name of the entities, modules, services, etc (without the relationship properties like “companyId” and “clientId”) and we’re looking at 50+ files changed for each entity. Then the reference properties, then migrations. Fun without tests.

With the tight deadlines I didn’t have enough time to fix it in the beginning, now the system is growing and it’s becoming a mess. Of course part of it is my fault. Maybe I should’ve sticked to a plan and continue the wrong naming, idk. When things are a mess and you contribute to the code, you are also contributing to the mess.

I'm dumbfounded by the number of people that believe the software development world is either black or white.

Just like everything else in the world, tests are not always needed. Sometimes they're absolutely necessary and not writing them implies tons of issues and tons of time to fix them. And sometimes they're absolutely useless, and writing them is a waste of time.

[-]

ruminatingonmobydick@reddit

I worked for a large fintech company that unofficially said testing was women's work. I'm not normally one to be derisive to brogrammers, but I think there's a pervasive culture of man-children in silicone valley and beyond that insults the three quarters of my life I'vespent orderingones and zeroes. My dad taught me that if you won't change a tire, you don't deserve to be behind the wheel. I'd say if you won't test your code, you shouldn't be a dev.

[-]

deftware@reddit

Sometimes you just want to make stuff happen ASAP, and tests are antithetical to that.

[-]

gjosifov@reddit

Of-course devs don't test, however the problem can't be solved with devs should do tests

There a lot of problems with testing ecosystem

Testing literature is very bad - most authors think they are smart when they make claims like - tests can only prove the presence of features, not the absence of bugs. Sherlock how about step by step tutorial how to test ?

This means that even the testing ecosystem doesn't take testing seriously

Most software today is component based software - that is why it is easier then ever to produce software, because there are a lot of components (framework/libraries) that will solve your issue.
Nobody parse pdf file byte-by-byte, they use pdf libraries

Well, in component-based software testing is hard, because most software components don't provides testing part of the component
This leads for 3-rd party testing frameworks having to hack the component in order to test it
and this hacking has to be done by the devs

Can component based software provide testing part ?

it will be hard if it OSS and authors don't have budget for it + most components are OSS

and lastly

Management - Given the nature of literature and component-based software it makes testing more hard and
and in most cases useless
So naturally the management thinks testing is low priority and it can be more easily done with Manual QA

[-]

nfjsjfjwjdjjsj4@reddit

Where i work (not as a dev, as an end user of our in house software) no one tests anything. If i report a bug they ask me to test if the fix works on a good day.

In some areas they dont even have the permits required to test.

[-]

nfjsjfjwjdjjsj4@reddit

Where i work (not as a dev, as an end user of our in house software) no one tests anything. If i report a bug they ask me to test if the fix works on a good day.

In some areas they dont even have the permits required to test.

[-]

kingius@reddit

Seems like the quality of developers might be dropping over time, if this is true. Perhaps AI generation is giving developers a false level of confidence in the code they are checking in.

[-]

PM5k@reddit

You have some tickets on the board.. some familiar from the past, some are not. Perhaps you pick a novel challenge… You write garbage to make something work. You write it fast and loose cause the sprint has other shit on as well. So you do the PoC and then it works. You go back and refactor it so it’s not so shit anymore. As you do, you might think - I wonder how this could break… so you write a test. Maybe five tests. You’re confident it won’t break now. A worm burrows in your ear. “It’ll still break” the worm whispers. So you write some edge case tests. Somewhere in the office, a chaos monkey slams two cymbals together — the junior dev broke prod. You smile, that used to be you a long time ago. Now you have your tests and your polished code and you push that to staging and watch the test suite pass, success as expected and the worm is pleased. You stand up and go make a coffee before yanking a ticket off the board for your next task. When you make your way back to the desk you notice a slack message from QA - “your X broke when I just Y”. You scream internally, the worm screams, in the distance you hear the cymbals.

Junior devs either test literally everything or don’t test at all - either way they’ll break shit. Senior devs test only what makes sense from experience or not at all. Those more senior still will test behaviours over units or not at all. And QA have no clue that they are part of the test suite - perhaps one of the most important parts. Because sometimes you just don’t know every edge case, you can’t possibly predict what will break. And you’re biased anyway so what the fuck do you know about testing your own code the way a clueless user or uninvolved QA tech would?

Jaded people don’t bother because shit will break anyway. Responsible people will test what they have experience in seeing break and leave the rest to God. Psychopaths without families or desire to have free time will test everything and obsess over tests. Shit will break. Same and practical testing is still worth it. Don’t bother trying to read tea leaves for the rest. Just let someone break it early so you can go fix it before this happens in prod.

[-]

ShenmeNamaeSollich@reddit

Unless you “learned to code” entirely in the last ~10yrs, chances are none of your initial exposure to programming included instruction on how to write tests … Especially more complex things requiring mocked services etc.

You learn variables & data types & control structures; then you learn OOP; then maybe you build a game or a website frontend & backend & a database. Then you play with DS&A.

At no point in many undergrad CS classes or bootcamps is “testing” more than an afterthought.

Same was true of most online tutorials, programming language books, video courses, framework documentation, etc, that I saw from 2010-2020 when I was first muddling along.

You wanted to work with Angular or React or iOS or some other hot new thing? “Testing” was literally an appendix or throwaway chapter at the very end of the Docs for all of those.

Sure, you could maybe buy a separate dedicated book about “testing in [language/framework],” but who has time for that?

Literally only in the last ~5yrs or so have I seen an emphasis on, and materials that explain, specifically how to write tests with examples beyond something stupid & trivial like “assert(1+1).equals(2)”. (Shoutout to Google’s Android courses that incorporate realistic unit tests & mocks & e2e tests early on).

Testing has very much been a “draw the rest of the fucking owl” endeavor for me. Devs who aren’t taught to test as part of “learning how to code” overall aren’t going to write tests on the job either, unless there are already good examples in place to build on.

Testing may be viewed as “additional work” as opposed to being an integral part of the process or outcome.

On top of that, we have a solid 15-30yrs of entrenched legacy web & mobile code out there written in ways not very conducive to adding tests afterward. There’s a lack of good examples and a lack of mgt support for retrofitting things.

[-]

drinianrose@reddit

I used to have a developer who would swear that he tested his code but it nearly always failed QA. I finally asked him about how he was testing…. his definition of testing was compiling it. If the code compiled, he said it was tested.

[-]

rperanen@reddit

The biggest benefit of testing is not necessarily the tested code but known dependencies. Good developers are lazy and if writing tests takes a long time then they change code more testable which forces it to be a bit more loosely coupled.

End to end tests are great but fixing a bug is faster if code is properly tested. In that sense unit and end to end tests complement each other.

Sadly, humans are slaves of their habits. I have had long and tedious arguing with some self proclaimed geniuses who simply do not want to take care of unit testing. They rather run code like it is late 90's or early 00's than change their way of working. Cherry on top is that writing tests takes too much time when project is late and project is late due to shortcuts on qualify assurance.

[-]

agk23@reddit

So I started my own software company. I was the original developer (self taught over 20 years) but now have 9 software developers. I sold the company in March, but still run operations and drive product decisions.

We have 0 tests. Most of our application is basically a CRUD app that I think automated testing in that situation doesn’t provide a lot of value. That being said, I’d never advocate to do 0 tests, and hopefully we get to a point where we implement testing but honestly the value of faster dev outweighs the risk for us right now.

[-]

ykafia@reddit

Unit tests are not sacred, I am in charge of a 3 BRMS services, never wrote unit tests.

Main reasons for that are :

I work alone
Most of the logic is written in a DSL that can be analyzed by tools or doesn't generate functions or classes that can be tested.
Une rule change could impact hundreds of unit tests since everything depends on everything

I preferred writing myself a tool that analyzes changes and generates a dashboard ready to be used by business to understand the impact of changing one rule.

What I'm trying my best to do for future devs that would replace me is keeping everything simple, as explicit as I think is best and documenting everything, from business motives to the code I write.

[-]

acroback@reddit

You will be surprised to know that a lot developers I manage think QA is there to test their code and thus they don't have to do any system testing.

Bash4195@reddit

[-]

Positive_Method3022@reddit

I was bullied a lot for trying to use best practices, then I gave up. I realized that I can't fight against the environment.

[-]

confuseddork24@reddit

I was at an e-commerce shop helping build out the data warehouse. They used Google analytics and the business logic we had to implement was super fragile and spaghetti because the Google analytics implementation was consistently inconsistent across web, iOS, and Android. I brought up standardizing naming conventions, string formats, and some other basic things and asked why they don't test the tagging implementation so they don't accidentally break downstream analytic tables. Turns out they didn't have any testing, at all, period.