How to convince managers that developer-driven automated testing is valuable?
Posted by spierepf@reddit | ExperiencedDevs | View on Reddit | 65 comments
I've been a professional developer for about thirty years. My experience has taught me that I am my most productive when I use automated-test-based techniques (like TDD and BDD) to develop code, because it keeps the code-build-evaluate loop tight.
Invariably however, when I bring these techniques to work, my managers tend look at me like I am an odd duck. "Why do you want to run the test suite? We have a QA department for that." "Why are you writing integration tests? You should only write unit tests."
There is a perception that writing and running automated tests is a cost, and a drain on developer productivity.
At the same time, I have seen so many people online advocating for automated testing, that there must be shops someplace that consider automated testing valuable.
ExperiencedDevs, what are some arguments that you've used that have convinced managers of the value of automated testing?
dauchande@reddit
At this point, I don’t obsessively push test first models. But the purpose of QA and Developer focused testing are completely different. TDD/BDD is really Specification Driven Development. It’s a requirement in my opinion as a professional engineer.
Kent Beck used to have a podcast episode called Developer Testing and the premise was that the purpose of TDD was for accountability. The tests prove what you were intending to do. You are not using testing to find bugs, you’re using testing to verify a design. And the tests keep you from accidentally changing it and then committing it to your repo without realizing that you’ve changed the behavior of your application.
My recommendation is not to talk about technical things like TDD with non-engineers. You’re wasting your time and theirs. Just do it.
Atupis@reddit
Yup this same with CI/CD, linters etc. You just have agreement with team and then think it as part of work so you don’t mention them with nontechnical managers.
jenkinsleroi@reddit
Your managers are stuck in the 1980s, or they are not technical managers. If they're not technical, dont even tell them you are writing tests. Just tell them you are doing software design.
coderemover@reddit
This won’t work in the long run, because how do you get budget for CI? The real value in tests is when they are executed frequently by everyone and catch bugs as soon as they are written.
jenkinsleroi@reddit
If you have to ask for budget for CI, then you are stuck in the 90s. if that's the debate im having at work, then it's time to quit and find a new job. TDD is also not about QA, so catching bugs is not the primary value.
coderemover@reddit
Its not about me. I assumed they don’t have CI, because they don’t have the tests. So they would have to ask for it. Surely, in our company everything goes through CI automatically. But there definitely is someone who pays for that (and those are millions).
jenkinsleroi@reddit
Meh. That's a strawman problem. Solving sudoku isn't a poorly understood problem, so tdd doesn't get you that much.
There are things that can go poorly with TDD, but it's not snake oil. And the alternative where you test last is usually worse.
And like I said, if you're at the kind of company where people are questioning the value of CI, it's time to find a new job. You arguably shouldn't have even joined in the first place.
coderemover@reddit
You didn’t read that, did you? It was poorly understood problem by Jeffreys. This series proves that TDD is useless for poorly understood problems. It’s also mostly useless (except the finding bugs part) for the well understood ones - because if something is well understood then I can just write a good design with or without TDD just as well.
jenkinsleroi@reddit
I did read it. Did you? There's a lot of back and forth in the commentary about which approaches work. And even Norvig is quoted as saying he thinks test driven design is great, he does it frequently, and that the difference between the two attempts is not significant.
If you don't know the algorithm to solve a problem, of course tdd isn't going to help you. That's why the blog is a strawman. You chose a toy problem with anecdotal results by two people for a solved algorithm problem.
There are actual properly performed empirical studies that show mixed results, just like the commentary. So I'm not saying that TDD is a cure all. But if you go at it like it's a QA exercise, you're gonna have a bad time, which is the point.
And stop projecting your insecurities into the world. I never said anything about your company.
coderemover@reddit
I’m not saying it’s a QA only exercise. Ok, EOT from me, because this is the third time you’re claiming I said something I haven’t.
earlgreyyuzu@reddit
There are places that don’t let you write tests?
I‘m always bewildered by how “this helps me do my work better” is not a valid reason for anything these days.
Yakb0@reddit
There are places with a really strong QA department, and writing tests is a political fight. QA doesn't want anyone stepping on their turf.
kasakka1@reddit
It seems weird that they wouldn't want to reduce their workload by having some of it automated. Fear for job stability?
VisAcquillae@reddit
Places, heh, even markets.
At a place, I have been unironically told that "devs can't write tests, because it takes time away from development". I probably don't have to mention how many man-months went into hunting for bugs and putting out fires.
I work in a market where you might be brought in as a consultant on "how to deliver reliable software", and the mere mention of anything test-related throws a grim veil over the room: "we can't invoice clients for testing, it's not development". Then, an untested mess that was within budget gets delivered and the clients spend double or triple the amount for bug fixes anyway.
narnach@reddit
CTO at the startup I started at 20 years ago was agains unit tests, told us to test things manually because it was faster.
The moment he got fired, is when my locally maintained set of tests became our project’s official test suite.
Good tests protect your future changes from breaking features you’d like to remain working. It is really not that complicated.
Woah-Dawg@reddit
Yes that’s nuts
pwnrzero@reddit
I wish we had more developers like you.
Exact quote from one of our SENIOR developers, "what are unit tests?"
Justin_Passing_7465@reddit
If he is asking because he has no idea, that is bad. But he might be asking because there are many conflicting definitions!
Specifically, the per-function and per-class definitions are pretty stupid, and not at all what was originally intended. If your unit tests do not survive refactors (even refactors that totally restructure class hierarchies, totally overhauling function call chains), they are shit tests. Your tests should not only survive large refactors without changing the tests, but your tests are how you know that your refactor was really a refactor that did not change outward system behavior.
Forget the cargo-cult lore that your fellow devs taught you about unit tests. Go read Kent Beck's "TDD by Example".
chaoism@reddit
"why are you writing integration tests"
People say this!?!?
SnugglyCoderGuy@reddit
Oh yeah.
"Why are you wasting time with tests, we have QA for that"
recycled_ideas@reddit
Integration tests are valuable, but they're extremely easy to fuck up.
Above almost all other things, your test suite should be fast. If it is not fast, it will not get run by developers and it will be bypassed in gated checkins and releases. Speed is literally so important that it's right behind actually testing the code. Integration tests do not have to be slow, but man are they often slow.
The next most important thing is telling you where the problem is as precisely as possible. This is where well written unit tests shine, you know exactly which unit failed and that should take you to at most a handful of methods. Badly written integration tests can be as vague as a user reporting a crash.
A lot of developers like integration tests because you can write them without having to think about testing while you write your code and you can put a lot of code under test with only a few tests and there is genuine value in testing the glue that brings all the separate pieces together because that glue code can fuck up badly.
But slow tests are basically useless and tests that don't tell you what the problem is are frustrating and too many people write integration tests that are both.
Adorable-Fault-5116@reddit
The last time I heard this was 20 years ago, when the client refused to pay for regression tests, then complained three months later when every build broke in random ways. That was a funny meeting.
carrotcakeofipanema@reddit
2 years ago my company hired a dev to build a new project. Since the beginning I have been mentioning that test should be written. “It was not the right timing” said dev and management instantly agreed. Now this sh*t is getting deployed and breaking. Guess who got recently asked to fully test it
Advanced_Engineering@reddit
On my last job I Iiteraly had to beg my manager to allow me to write tests.
Relevant-Ordinary169@reddit
Why wasn’t that just part of your workflow?
Advanced_Engineering@reddit
Beats me.
pheonixblade9@reddit
I did consulting and I got removed from a project with an insurance company for writing unit tests. Wild stuff.
Relevant-Ordinary169@reddit
Even without them, they would’ve canned you for some other contrived reason. You dodged a bullet.
ralian@reddit
I’ve seen sooo many low quality integration tests that I’m not shocked that people have come to this conclusion
PandaMagnus@reddit
You'd be surprised. I work with a team where we're constantly told that that's "more of an SDET thing," so the SDETs end to trying to handle coverage that serves developers, manual QAs, and BAs.
It's a toss up on if the developer thinks they should be more proactive in integration tests. The typical argument against is usually "I just don't have that mindset and won't do as good of a job."
It makes me sad.
Inatimate@reddit
Convincing them is not worth it
Adorable-Fault-5116@reddit
I'm confused by the body of your post.
You are talking about not being allowed to do TDD, I think, but your manager is telling you not to write integration tests and only write unit tests.
Putting to one side that you should write integration tests, how are they stopping you from doing TDD? Unit tests is what you want for TDD, so the loop is faster.
On integration tests, terms are wishy washy, but depending on what you mean you should just write them? Just call them unit tests to your manager, and then don't mock what you were going to mock. IDK what language you're in, or what dependencies you need, but testcontainers exists these days, no one will be the wiser.
aq1018@reddit
From my experience as a technical consultant here with 20+ years of experience, to persuade a technical founder / manager, you need two things: trust & proof of value. If you are in the company long enough and done enough high visibility, high value tasks, you will have his trust. Then you can explain automated tests in terms of values. e.g. it is an investment / assets. It will work 24/7 and "QA" your code in minutes instead of hours for free. Why Pay QA hourly when you pay to write your test once use it forever, etc... But yeah, you need to gain trust first. non-tech owners / founders doesn't have the tech background and is constantly in fear of making the wrong decision and thus tend to be very conservative.
BEagle1984-@reddit
It’s simply an accepted fact nowadays, that a DevOps team performance and efficiency is measured by the DORA metrics and that the élite teams are the ones deploying to production multiple times a day. These are facts, and you can find tons of literature talking about this, starting with Accelerate: The Science of Lean Software and DevOps (2018) and the annual State of DevOps reports.
Unfortunately, you’ll never achieve an élite velocity if your workflow consists of hours of manual testing. Really, is this simple and everybody should be able to understand it in these terms.
Continuous testing is really one of the key factors that differentiate high performers from low performers. It’s a prerequisite.
titpetric@reddit
Let me answer the question with another question:
Does the company have a well defined testing strategy?
k3liutZu@reddit
Why do you need “approval” to do your work? Can’t you just write your tests as part of development as you would usually do?
canderson180@reddit
Ask them how confident they are that regressions aren’t being introduced to the system, and then ask QA how fun it is to maintain a set of e2e tests to handle every permutation of configuration as your feature set grows.
I can’t believe that in this timeline someone would push back on this. Asking about candidates’ disposition and understanding of this concept is one of my first phone screen criteria.
ramenAtMidnight@reddit
Literally the best answer to this question, and this low down. Baffling how redditors think quips should be more visible than actual attempts to answer a question
Zero219@reddit
Why would you even discuss writing tests with manager? That’s non of his business.
dethstrobe@reddit
TDD acts as living documentation (and if you use playwright and test2doc it becomes literal documentation for non-technical stakeholders. Also a note, I'm the guy maintaining test2doc, so take this recommendation with a grain of salt). So if you want to what your software can do, no better place to find that then in tests.
Reduce bugs. Who likes bugs? You're manager, i guess. Not only that, how do you know a bug won't come back? Automated regression testing will prevent bugs from returning in to the system before QA needs to even look at it.
Makes your software more accessible. What, do you hate blind people?
QA can literally be doing other things that are more valuable, like transitioning to engineering or PM. They literally have so much context, your manager would be stupid to fire them and lose all that context, even if you hypothetically do not need them anymore.
oakman26@reddit
I tried to integrate playwright and it was awful, took forever and was flaky. Never had much luck with anything more involved than unit testing for frontend code.
dethstrobe@reddit
I've found all the e2e testing frameworks to be flaky, selenium, cypress, puppeteer, etc etc. Playwright seems just as good as the other ones.
tonydrago@reddit
I didn't see the point of test2doc
dethstrobe@reddit
The idea is that tests are living documentation. Which is great for engineering, but not so much if you're a non-technical stakeholder.
But let's also say you're in a highly regulated industry that requires compliance (health care, defense, finance). You need to spend time to make sure your software is documented anyway, so if we can automate that, then you now have up to date documentation that mirrors what your software can do, and on top of which, when you remove a feature, and remove the tests, and the documentation is updated at the same time to reflect the current functionality of the software.
tonydrago@reddit
But what exactly does the tool extract? Is it just the names of the test methods?
dethstrobe@reddit
Yes, the titles, as well as playwright has a thing called a step to make note of a small unit of the test (or you can follow something like Gherkin style), and you can add screenshots to each step.
Like wise, since it is outputting markdown, you can put markdown in your titles to render something more specific. It does require a paradigm shift in writing tests, actually describing in blocks what the test is doing.
diablo1128@reddit
I don't try to convince managers though arguments. I show management how what I want to do helps solves concerns they have. If I cannot solve a concern of management with what I want to do, then I just don't expect it to get implemented. They may appease me with putting it in the backlog and revisiting it later, but I know it will never get to priority.
In your specific case could you explain how you would write less bugs or something along those lines? You could explain how it's cheaper to find and fix issues the close it is to the SWE doing the work. Maybe management bites or maybe then think whatever is happening now is fine and they will absorbed any costs associated with perceived inefficiencies.
In that case maybe you can write the automated tests and hid it behind implementation time when asked about status?
It seems like how you want to work does not mix will with how the company process is laid out. If management does not want to accommodate you some how then there may not be much you can do.
NekkidApe@reddit
This. Always this. You can't have a sensible discussion with management about your tools - and imo you shouldn't. They hired you to do a job, you do it using the tools and skills you need to.
With management, it's always good to speak their language. Money. Talk about how it makes or saves money.
TDD makes you faster, more money. Makes bugs cheaper to fix. Improves customer satisfaction and retention.
rk06@reddit
tell them. automated test will save 5 days of software engineering effort
Certain_Syllabub_514@reddit
I've had similar discussions at previous work places, including the question: "who's going to test the tests?".
That place was totally against me writing any tests (including unit tests). They also fired the whole QA department because they were finding too many bugs and slowing releases down.
My response at the time was: "I write the tests once, test them once, and then those tests can test that code thousands of times with zero extra work." They still didn't want me "spending" time to write unit tests.
UntestedMethod@reddit
Holy shit now that is unhinged.
maxip89@reddit
It strongly depends on which environment you are in.
When you are in a fast pacing environment, tests can even hurt your productivity.
When you are in some environment that has a very important (business critical) then tests are the way to do.
Why is this the case? The problem is, that you have to adjust sometimes other tests. This time is increasing with the amount of tests you have.
I saw managers argueing "why adding a new column to a table takes 2 weeks". Simple answer, at the kindergarden starter project (or even microservice without any "We have everything in a library") the dependency to other tests is low. When the project grows and grows you will see that your development performance goes down. Additional to that, sometimes are bugs just accepted on production and will be fixed when they are found.
This is just my observation.
allllusernamestaken@reddit
I stopped fighting over bullshit like this and moved to a tech company.
Certain_Syllabub_514@reddit
Yeah, I moved to a company that cares about testing. Even to the point of A/B experiments on relatively minor features to make sure we're not negatively impacting sales.
BayouBait@reddit
If you have to convince your managers then you need new managers.
00rb@reddit
My argument is as follows:
- The high visibility prestige project won't take 6 weeks, it took 12 weeks
My response to what I was working on:
- The high visibility high prestige project, of course
Piisthree@reddit
Only 15 years here, but I think I have some ideas. Managers are bookkeepers, communicators, and timeline trackers. They really should have NO say in how we get the target system built. None. You and your engineering team have to create the pipeline to create, deliver, and maintain your system. Automated tests (thorough but also within reason) at every step are critical to that, and those are your team's responsibility. They should be treated as a non-negotiable when doing the planning and implementing. That's just the end of the story. Managers shouldn't ask why they are beneficial because it's just none of their business how the job gets done. The good managers will understand, but it doesn't matter if they do.
Abject-Kitchen3198@reddit
I am more confident in pushing the changes I make without waiting on QA feedback and returning back to it after receiving it, knowing that I covered the changed code and ran all the existing test cases.
I can adapt code for testability, write code and tests using same skill set to keep it maintainable.
I know how my code change will affect the tests so I can adapt and plan accordingly.
I can use tests as documentation and communication tool while developing the feature or planning requested changes to an existing feature.
And still ship code with issues that QA will easily catch.
They can find bugs ang gaps through manual testing, review tests and suggest or implement test updates. Explore edge cases, performance or security issues that I have missed. Teach me about things I fail to address. Implement and maintain infrastructure for automated testing ...
Tiny_Arugula_5648@reddit
Seems to me a lot of you are living in the past. Code generation AI is perfect for TDD.. best of both worlds test coverage without having to do twice the work..
Senior devs are way better with AI augmentation.. if you know what you're doing it's like having an over eager ADHD junior dev doing it.. sure they go off the rails but you still move way faster..
jkingsbery@reddit
On Martin Fowler's bliki, there's an article about the Testing Pyramid (https://martinfowler.com/articles/practical-test-pyramid.html). Different forms of tests come with different trade-offs. There are some good arguments in that article for why you might want to do different types.
What I've found in the past is that there are some underlying assumptions that sometimes need to be questioned. Decreasingly now, but some people still take the approach that we don't need automated testing, because we're just going to manually test the thing for a week before pushing it to production. The accompanying shift that comes with test automation is that any feature should be able to go into production that same day. But that assumes you have ways to automatically validate whatever features, load tests, etc.
doberdevil@reddit
You can pay the cost now, or you can pay the cost later. But you're gonna pay the cost. (No, I've never had that argument work)
Plenty of people in tech think in terms of features delivered, regardless of quality. Or think it's someone else's job to do that thing. I've given up on trying to convince people who already know everything.
Talk to your friends in QA about it. See if you can get them excited about writing lower level test automation. Many would love the opportunity but need a good mentor to get them there. It doesn't matter how (who) integration tests get done, as long as they get done, and they're reliable.
roger_ducky@reddit
QA becomes the “bottleneck” if they have to do both “happy day” testing and “exceptional” testing. If they’re responsible for multiple teams it’s even worse.
Do people complain about QA filing unclear bug reports that are hard to actually reproduce? That’s usually a sign of overworked QA.
Developers should automate happy day/user acceptance testing. Takes 20%-25% off of QA load right there.
And foreseeable exception testing (easier to simulate in unit tests than integration tests) Takes half of remaining work off of QA.
QA can then review happy days test logs to confirm development didn’t miss something, or develop additional additional test cases with development if so, then focus on actual exception testing — finding, then reproducing errors so developers can see what went wrong.
alien3d@reddit
integration testing - approved but to create ui test , i prefer real human interaction test . Playwright okay but when complexity too much better human.
Punk-in-Pie@reddit
Hello me, it's me! I forgot writing this post, but obviously I did because I've been planning to do so for some time. Anyway, looking forward to what people have to say.
trojan_soldier@reddit
How many teams or devs will benefit from these automated tests? If only you, do it anyway as a side project. Don't expect that it will get credited, at least it will make your future tasks easier.
If many teams or devs or users reported many instances of bugs in production, you can use them as data points to support your case and get credited later.
If not many bugs and you are the only dev, forget about it. Just continue getting paid