I have unit/E2E testing ticket in backlog for over a year now … I guess I will never finish this sighs
Or, subscribe to Copilot, run your code base through agentic mode and be done in 20 minutes and cancel the subscription - for free!
Disclaimer: unit tests may not test your application
Let's say in a world where you knew you'd never have time to create those awesome, robust unit tests. Do you think doing something like this would be better than just not having any tests?
I'm gonna quote a coworker here on being asked whether he checks what Copilot generates for his unit tests: "if they light up green then no."
And a more serious answer: if just 10% of the tests actually make sense that's 10% more than before, and for the rest there's at least the classes ready to be filled with life. It's really a "not good not bad" situation to me.
The problem is that at that point you can't actually trust the tests to work properly. If you make a change and the test starts erroring, you can't be sure if it's your code that's wrong or the test that's wrong, you need to debug both.
The takeaway in that case is "I need to finally properly implement this shit". The typical action on the other hand is "disable the test and fix it when there's time".
Jesus Christ. Committing stubs to the codebase isn't ideal but its 1000x better than whatever the fuck this workflow is.
Bringing LLMs into engineering has to be the dumbest programming fad I've seen in decades.
Any time an LLM is in a position to make a decision is a failure.
You think i need ai to not trust my tests? You undestimate my power of ineptitude. Where do you think the models scraped all the brilliant ideas for "testing" from. It was people like me "fixing" tests by making them expect whatever the hell it is currently getting and light up green. I assume it probably is meant to work like that anyway, the test must be wrong... goes brrr.
Isn't this always the case? About a month ago I pointed out a bug in a piece of software initially designed by me then heavily refactored by another guy. He responded with "...but it passes the test." The problem is that a test failing does not tell you your code is broken, it tells you the test failed. That may be because the code is broken, or the test is broken, or the test is just not testing what you intend it to.
To be clear, not arguing for AI here (at present have resisted using it), just that tests are nearly useless even without it.
Tests aren't meant to be QA testing, each phase of testing has specific roles. Integration tests make sure your shitty checkout code didnt mess up someone elses shitty product code, security tells you early if your shitty checkout code broke someone elses shitty authentication code. E2E testing tells you if your shitty checkout code breaks someone shitty webkit-specific workaround.
They are not fool proof, they are an early warning system.
In theory, yes, tests can be wrong even when written by a human.
In practice, tests created by a human with intent are usually going to be right, but you might need to fix them at times. With LLM tests, you can't start with any sort of assumption that the test is testing what it's supposed to be testing for the reasons it's supposed to be testing it.
🤔
“These tests only look like they work. They don’t do anything!”
AI is already at my level, fuck
You ever worked in corporate where just getting vscode update goes through 4 rounds of approval? We now do have some AI available, but man it’s so shitty and all chats are directly seen by IT administrators.
That's robot work
it's finished, you are just having a hard time accepting it.
Our e2e testing task was sitting in the backlog for 2 years, left forgotten, until the new guy saw it and asked about it. It’s 3 years now
Nothing more permanent than a unit test in the backlog
print() driven development entered the chat.
Cheaper than breakpoints
let me just quickly comment out a few asserts here and there
Assert True is True
I think that can actually fail in javascript.
JavaScript is nondeterministic and you can’t convince me otherwise
One would think that empty program would do nothing
Yet, Javascript will make a way to: compile, show error, do nothing and do something at the same time
We don't need quantum computers, we have javascript!
So, JS is in superposition
Maybe that's why it supports "super" keyword
undefined variable "True"
Neutrinos go brrrr
Wait don’t comment that out I rely on that behavior
What's the difference/g
One uses proper unit testing. The other uses caffeine, self loathing, and random shit.
Which one is which? /s
And whats the Dev who uses both?
With error-driven development, the errors often pop up much later in production, so there's a higher risk of damage (which is nothing serious if you're making a website for a teenager who hired you on Fiverr, but it isn't great when you work on e.g. hospital systems, wildfire alert systems, etc). A well-designed test can catch issues before the code goes to production.
However, that's mainly theoretical. Designing tests isn't easy, often they're kind of half-assed, so you'll get errors in prod anyway.
There's the old joke where a software developer develops a bar, and the tests include asking the bartender for one drink, five drinks, 7 million drinks, ⅗ drinks, -π drinks, and it's all accounted for, but then a customer walks in, asks where the bathroom is, and the whole bar catches on fire.
It still helps, though, so it's generally good practice to have tests, you'll massively reduce the number of bugs reported in prod.
In my last job I had to deal with a lot of bad tests written for math libraries. As an overcorrection to that, the software manager wanted all low level math functions to have input checks for NaN/Inf. Well that slowed our software down to an absolute crawl. My suggestion that only high level "Algorithm type" code should have the initial checks and low level stuff that gets called 1 million times should just be weapons free was met with massive consternation from the same manager. I won in the long run.
Ah the long run win. My favorite as a grumpy senior dev. I like to say "I might be the first person to suggest this, but I won't be the last".
Lol, we use error driven development on our hospital systems.
The secret is we deploy the new version to sites that are under construction, and count on the user doing the hospital commissioning testing to catch any bugs.
Ideal? No, but it's not like the test driven development catches everything, site deployment is always part of it. If I was in charge I'd put tests in, but I'm not.
TDD is specifically a practice where tests are written before code is. You can still write tests after you write code, and before you go to production.
I don't know. The first step of TDD is to write a failing test.
Literally the point of TDD.
OP means "Prayer driven development"
I tested this thing manually one time, please god let it never be an issue again.
Apathy Driven PM. Just get it finished so I can be off this crap project to start the next pile of crap.
If-business-cant-define-requirements-nothing-is-a-bug driven developer
But the business can never define requirements…
Sounds like we can close that QE subtask then, great work
I let the runtime decide my fate like a true believer.
I think TDD (Test Driven Developer) is like pure discipline, and Error Driven Developer (EDD) is like spirits awaken through deep pain...
I channel the Omnissiah every time I launch my program in prod.
Test in production is the only way to go
You joke but it’s the only real test there is. Everything else is hypothetical.
Meanwhile fear-driven development is quietly sweating at the back of the room wondering how long this meeting will take.
I'm more of a CEO-needs-to-make-a-public-statement driven developer.
I like it, that's up there with the "find out about the issue from the news" development
if i hit run and it runs, to prod it goes
Error driven development? That sounds like rust
Yeah, they didn't specify compile-time or run-time; if it's the former, definitely Rust; otherwise, probably a C++ segfault.
Honestly, the more errors you can make compile-time errors the better.
That event being the approaching deadline
"You had to deploy yesterday feature that I mention today for the first time" driven development
"Error Driven Development" is what you do when your business users can't tell you exactly what they want, but they'll know it s wrong when they see it.
"No, this is wrong. Can you do it like this instead?"
Finally, after 5 revisions and 7 quick fixes, we're production-ready.
Time for a proper re-factor? Sorry, the sprint is already full of new items.
First off, utterly fantastic name; second, error driven development is actually compatible with the live fast die young / YOLO 4 LIFE / I am the Sonic the hedgehog of great ideas for web applications / I want things done yesterday of 90% of the clients I had when working with digital agencies.
You learn more in 1 hour of usage than you will from 1 week of reviews.
how come our product actually has something to offer, we only need tests to succeed
Puts Driven Development
I don't break the code, I throw exceptions for enlightenment
as my IT teacher said back in time: Programming by attempts
Test driven in theory.
Error driven in practice
No jokes, somehow my fastest way to develop is to write the whole thing and then deploy/compile and start going through the errors until I got all them fixed and my self esteem demolished by the silly stuff.
Doing it part by part testing small things takes a lot longer if developing for something old that requires like 5 minutes between compiling, building and starting up the server.
I also a lot of time debug while is building/deploying... and redeploy before the first deploy was over.
Test driven development is just error driven development with extra errors.
Did I share this in my works Slack channel? Yes. Did I get DM's with a guys name and LOL after it? Yes.
"Let's put it in the kitchen and see if it cooks!" Al Bundy
If those errors are at compile-time I am all for it
DDD: damage driven development We had a colleague that was an expert of this kind. Guy could write a code in two hours you wouldn't understand in a day
Tdd is error driven dev but faster
I’m just gonna send it.
Bug driven developer
/gen; Error UX is actually really important in prod though. Tests won't catch everything, and having good error reporting will dramatically simplify the oncall work of debugging issues. You might test that a specific condition triggers a specific error for known issues. But throw a good error code interface behind monitoring and you can start finding classes of unknown-unknown issues that your tests aren't catching.
In code reviews I usually care less about "have we tested every edge case" and more about "when it fails, what's that going to look like to users/support/devs?" (Obviously not saying do this instead of testing, just something extra to consider.)
Don’t kid yourself. You’re a repost developer.
Compiler Driven Development has entered the chat
Where is the AI-driven developer's seat at this table?
Server's down or they ran out of credits.
Meanwhile me, a rest-driven developer, because rest apis are no longer enough
Honestly, what drove my development was always hormones
I used to write VBA code. It has an "On Error Continue Next" statement......
VibeDrivenDevelopment: Always migrating to the latest and greatest.
Where prediction driven developer
You WILL do both. Test driven errors are the devil you know. So you're just making sure to not self inflict injury.
The only way how to do it properly!
tests take way too long to write
Let me just put a variable in this error message and run the pipeline again so in an hour when it fails again i'll know why
Error driven backlog
I-have-no-story-points-for-tests driven developer
i test WAYYY to much. often causes problems with productivity
I'm somewhat of a Production Driven Developer myself
You don't run tests because you prefer to catch and diagnose errors
I don't run tests because I never figured out how to properly write/use them
We are not the same
I'm a "i write test cases and then delete them because it's a lot of clutter." What does that make me
(The answer is a dick)
I go with AI absolutism, if the AI doesn't see the bug, it doesn't exist.
Test to see if there is error
You don’t need to define ALL of your unit test upfront. If you get an error then you capture it in your unit tests to verify you fixed it and prevent a future regressions
isn’t EDD and TDD the same thing, if you consider your test suite code
Yeah I do test driven development. I ship a release to the client and they test it and tell me what's broken.
CDMA: Customer-driven monitoring and alerting.
Incredibly stupid meme format
Dont-test-anything-until-client-reports-issue driven developer
TDD : Ticket Driven Development
BehaviorBug Driven DevelopmentJSOD – Job-Security-Oriented Development
RPOD = Resume Padding Oriented Dev
PROD Padding resume oriented dev
Seems like a good spin on yours?
Bug Analysis Development, or BAD for short.
There's no such a thing as "bug," only undocumented features.
It’s a feature department*
I’m more of an undeveloper. I break down large monoliths that have fallen over. Breaking down their macrostructures back down to bits for the earth to re-use.
Finally I understand why it's called an ecosystem
My first job out of college was setup that way. No tests, we did internal testing, which many of my co-workers did not, and the users/clients tested on beta, which many did not. Ended up sending several bugs to production because the original developers were dummies and would have a view that should be 20+ different views, 6 different apps, I'm more of a backend developer, and the users never tested right. We should have "promoted" some of the dummies who were "programmers" onto a testing subteam or create a testing team.
My first programming job was in QA. About a year in, my company had the brilliant idea of cutting costs by laying off the entire QA department. About two years after that, they went under.
Hmm.
This guy didn't realize it, but I and my supervisor would pass libraries we wrote onto him and he'd find bugs. Right hand on the Bible, I wrote guards to make them idiot proof, but he'd somehow mess up the call like not setting his app's name for a security lib or something like that on PHP and gun to the head he didn't know what an Object is despite holding a Java Dev position and having 10+ years of experience in C#.
I'm actually an incredible error magnet, which is why I work so well in QA.
I'm the person who does a simple git clone and ends up spending 4 hours with a t3 support person before they find out that I somehow created an invisible directory around my branch that was preventing it from pushing and pulling properly, despite having done absolutely nothing unusual while cloning.
I'm the person who used a bpm calculator (you tap a key in time to the rhythm and it tells you the bpm of the song) and managed to get NaN. And I could duplicate it every time.
I can and will find the most obscure bug in your code, not because I'm stupid, but because I'm supernatural.
This guy was just stupid, but he would be great as a QA Tester. For God's sake, he spent a long time working on a Ubuntu Linux VM project and didn't know that file paths are case sensitive on Unix-based systems. Then when we called him out he goes "How am I supposed to know that?". Seriously?
That depends on whether or not he can write an error report with the requisite information when he fucks something up, I guess. Or if he's really that valuable then he would be part of a dyad where the other half served that function.
silence stupid driven QA tester,
Satan's chosen One driven QA tester is speaking
Mods, can I have this as a flair?
I once worked with a QA guy like you. He was able to find the most insanely-subtle bugs in what should have been rock-solid code. The phrase that guy heard the most was "how did you find that??"
I would love to know what the bug was. Obviously, it's dividing by 0 for some reason, but what was happening to trigger that?
Maybe he's got millisecond-accurate timing so that the timing period delta was 0 and was being used as a divisor...
We never found the cause. I was the only one ever able to replicate it, and even doing it in front of the dev (virtually, because remote), didn't help. I would deeply love to know how it worked myself.
Ok we should get some beer together
I loved working with a professional QA team. When we all switched to "devops which means you test and deploy your own code so now we can fire QA!", things went to hell pretty damned fast.
whenever i update my client on the newest patch i just fuckin
How to get client staff embedded at your site in one easy step.
Users are the best testers I always say 🤪
Fucking hell. Worked for a startup where one of the young leaders felt this was how the best innovation was done.
The MSFS method
👆
Errors? That's the stuff only reported by clients.
We call that Agile.
I had a professor that called that “hope to God programming.” One writes the whole thing and then hopes to God that it works.
The client is the best QA
The fuck-it-we-ship-at-dawn type of developer I see. A man of culture.
A.k.a. Scream Test Developer.
More don't fix it unless is reported by client.