Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "!tests"
-
My morning:
Me: Why did you just delete the failing unit tests?
Intern: I debugged it for a while and found one of the other developers broke it with his recent changes. I couldn't fix it.
Me: Did you let him know he broke it?
Intern: No.
Me: So you just deleted it and decided to pretend the feature isn't broken?
Intern: ... No ... I mean ... well you told us yesterday we needed to have all the tests passing.
(I NEED a stress ball people)30 -
Working with a team of interns, pointed out a bunch of unit tests are failing, they said they would take care of it.
10 mins later they opened a pull request to delete the tests that were failing.
fml, fml, fml, fml ... and ... oh yeah fml10 -
When your colleagues have no tests for their code and tell you not to touch it, because it WORKS!14
-
About 11 months I posted that my wife was pregnant. I now have upgraded to son 1.0. All without writing any tests!14
-
The past 2 years where I work:
Me: hey let's use git instead of ftp!
Boss: should we?
Some time later: he is loving it...
Me: hey let's use trello instead of excell!!??!
Boss: huumm.. Dunno... Should we?
After much convincing: whole departments are using and loving it....
Me: hey let's move from rackspace to DO!
Boss: huumm... Convince me...
Year latter: everything smooth and muuuch lower prices... Managing 6 servers instead of one...
Me: UNIT TESTS!!!
Boss: nah, this but a waste of time...
For real? Get a grip man, I only encourage solutions tested ( no pun intended, or is it ) by me for a long time...4 -
So what does everyone think about unit tests, do you do it?
My own experience is I've seen people on my current team disable failing tests...12 -
"Can you work on this ticket? It's kind of urgent."
-- "OK"
"And could you please not refactor? Just get this done."
-- "Why? What's the issue?"
"The logic is complex. We should not break it."
-- "Erm, that's what the tests are for. So yes, if the need arises, I'll refactor. The tests are my guidelines if the logic breaks or not."
There's a reason we create tests. So let's not hinder code base improvements by some random fear that stuff might break.
If breaks due to refactoring, we'll fix it by adding a valid test case during and then fixing the bug.
If my refactoring does not break the tests, I'll assume the code base is stable.
If your code is untested, then we have a complete different problem.3 -
Heard a fun quote from a project manager today:
"Naaah we don't need tests, that project is so small it wouldn't be worth it"
Seconds later: "Why does this keep breaking all the time and we only notice it once deployed?"8 -
* Updates and adds unit tests *
* Runs unit tests *
* All tests pass *
What the fuck? I'm not THAT good to write tests that pass on the first iteration.
* Runs unit tests *
* All tests pass *
Someting's not right here.
* Checks terminal *
FUCK I'm in the wrong project folder2 -
Me: This is good, but here’s a small tiny change that will make it even better!
Tests: 1 success, 3628 failures, simulator freezes and crashes computer
Me: never mind... -
People who try to justify not writing unit tests are the same as those who try to justify not using a condom.
You'll be sorry later.4 -
"We need to reduce the scope of the project, guys... What if we don't make tests? They're taking some time do write, so..."
Yep. Let's compromise the quality and call it scope reduction. It will make wonders to our roadmap 👍6 -
I was asked by our tester and scrum master to ignore some failing unit tests yesterday. The tester literally said "no time for tests, we need the build now". The scrum master is also a tester and agreed. I dont think I can respect either of them as testers anymore.3
-
Saw this from a friend of a friend of a friend and made my own meme.
2 unit tests 0 integration tests. Hacky code to fix it.3 -
Why... why the fuck do people write unit tests and then comment out the god damn fucking assertion lines....
Like what the flying fuck? Cool, we can get some code coverage marks but for fuck sake actually let your tests do their fucking job!!!
Oh, the asserts fail?
Well fucking sort that shit out instead of commenting them out.
I don't get it, if you're going to write tests, fucking test something with them, or we'd be better of without them.7 -
I now know why people don't write tests.
Been trying to get started with React unit tests for weeks now.
Hope Driven Development FTW.9 -
I jump on an existing scala project.
git pull && sbt compile test
Tests are failing.
Me: "Hey team, the tests are failing."
Team member: "That cannot be. They were passing for the the last run."
Me: "Did you run them locally?"
Team member: "No, on Jenkins. It was fine."
I check Jenkins.
Me: "What do you mean it's fine. The last successful deployment was on the end of May."
Team member: "The Pull Request checker always went through successfully."
I check how our Jenkins tasks are configured. It's true that the Pull Request Checker runs successfully yet due to a "minor misconfiguration" (aka "major fuckup") the Pull Request Checker only tests a tiny subset of the entire test suite.
Team members were were fine if their Pull Request got the "Success" notification on bitbucket's pull request page. And reviewers trusted that icon as well.
They never checked the master run of the Jenkins task. Where the tests were also failing for over a month.
I'm also highely confused how they did TDD. You know, writing a test first, making it green. (I hope they were just one specific test at a time assuming the others were green. The cynic in me assumes they outsourced running the tests to the Jenkins.)
Gnarf!
Team member having run the tests locally finally realizes: "The tests are broken. Gonna fix them."
Wow. Please, dear fellow developers: It does not kill you to run the entire test suite locally. Just do it. Treat the external test runners as a safety net. Yet always run the test suite locally first.4 -
Some former colleague just blatantly commented out units tests I wrote for his build to pass. What the...7
-
Today I fell down the rabbit hole.
I've been writing some automated tests which found an asymmetry in our algorithm which I think is caused by an off by 1 in even input dimensions.
Change input to odd dimensions, crash due to out of bounds exception.
Switch to debug mode to try to work out why we crash, failing asserts for default function arguments with no obvious reason beyond a helpful message saying they're unsupported.2 -
I did a job interview recently for a company and the test was something like this.
In ruby, write a web server that will serve a specific line number from a text file.
I thought up a simple solution and a more advanced solution, but I opted to go with the simple solution and submit my work quickly. I made a nice web server with tests and everything and it used the sed command to get the line number from the file.
Now, they had various instructions, like it had to perform. They asked how it'd perform with 10G, 100G files. I thought "Eh... it'll be alright."
The solution they were looking for was the "advanced" solution that I thought up, which involved storing a binary file of 32/64 bit integers that reference the byte-offset of the line they're looking for. Basically a binary index file.
This violates all of my sensibilities, because I would never build a database indexer like this using ruby, of all things.
I thought it was a stupid test, and how do these companies honestly expect me to spend hours coding and then tell me I didn't go far enough? It's unethical.
I actually followed-up with the "advanced" solution a couple hours after hearing I was out, just to show them that their process is flawed.2 -
My co-worker not only doesn't create unit tests, he comment out my own unit tests after he changes the code and the test breaks.11
-
*** writes unit tests with great zeal and fervor ***
IDE is reporting 85% line coverage, woohoo!
*** grins like a bastard, thinks it's perhaps time to stop and celebrate ***
*** runs branch/conditional coverage... ***
37%
*** facepalm ***3 -
"We don't have time for writing tests"
"Yeah we could write them but only if the client paid us for that"
"You can just test new features manually!"
- Most devs of our mobile team.
Every day they're fighting with bugs and when they're fixed, a couple more pop out of nowhere.
Dear god help me.5 -
Personal Project:
Code lives in gitrepo, commits to master are automatically unit tested and if all tests work it will be published to production
At Work:
"If you're done put this .bat in the project folder, it will copy everything in it per ftp to production"1 -
I got some work on a new project so I ran the 500, or so, unit tests and it took almost 3 minutes. Everything was mocked and no external dependencies so I got curious as to how on earth they could take so long.
I found some suspicious code doing a while loop over a date range incrementing by 1 day each time. It turned out the tests didn't initialise the start date which defaults to 01/01/0001, and there are 5 scenarios!
I got test execution down to a respectful 10s.5 -
We've had a bunch of flaky tests in our repo for a while now that no one could be bothered to fix; we'd just re-run ci until it's green. Today I looked into it and I was inspired to make this meme, because I lived through it.
Adding logs to investigate just lowered the fail rate making investigation more difficult. I do have an idea of what it might be though so, we'll see tomorrow.3 -
"I'm almost done, I'll just need to add tests!"
Booom! You did it, that was a nuke going off in my head.
No, you shouldn't just need to add tests. The tests should have been written from the get go! You most likely won't cover all the cases. You won't know if adding the tests will break your feature, as you had none, as you refactor your untested mess in order to make your code testable.
When reading your mess of a test case and the painful mocking process you went through, I silently cry out into the void: "Why oh why!? All of this suffering could have been avoided!"
Since most of the time, your mocking pain boils down to not understanding what your "unit" in your "unit test" should be.
So let it be said:
- If you want to build a parser for an XML file, then just write a function / class whose *only* purpose is: parse the XML file, return a value object. That's it. Nothing more, nothing less.
- If you want to build a parser for an XML file, it MUST NOT: download a zip, extract that zip, merge all those files to one big file, parse that big file, talk to some other random APIs as a side-effect, and then return a value object.
Because then you suddenly have to mock away a http service and deal with zip files in your test cases.
The http util of your programming language will most likely work. Your unzip library will most likely work. So just assume it working. There are valid use cases where you want to make sure you acutally send a request and get a response, yet I am talking unit test here only.
In the scope of a class, keep the public methods to a reasonable minimum. As for each public method you shall at least create one test case. If you ever have the feeling "I want to test that private method" replace that statement in your head with: "I should extract that functionality to a new class where that method public. I then can create a unit test case a for that." That new service then becomes a dependency in your current service. Problem solved.
Also, mocking away dependencies should a simple process. If your mocking process fills half the screen, your test setup is overly complicated and your class is doing too much.
That's why I currently dig functional programming so much. When you build pure functions without side effects, unit tests are easy to write. Yet you can apply pure functions to OOP as well (to a degree). Embrace immutability.
Sidenote:
It's really not helpful that a lot of developers don't understand the difference between unit, functional acceptance, integration testing. Then they wonder why they can't test something easily, write overly complex test cases, until someone points out to them: No, in the scope of unit tests, we don't need to test our persistance layer. We just assume that it works. We should only test our businsess logic. You know: "Assuming that I get that response from the database, I expect that to happen." You don't need a test db, make a real query against that, in order to test that. (That still is a valid thing to do. Yet not in the scope of unit tests.)rant developer unit test test testing fp oop writing tests get your shit together unit testing unit tests8 -
> creates new PR for open source project
> runs tests locally before pushing
> pushes
> waits 8h (not kidding) for appveyor checks to complete
> tests failed
MOTHERF- -
Project day 1. CTO: everything should be covered by automatic tests.
Project day 30. CTO: listen, we have lot of work in the pipeline now and we need to prioritize. Please don't spend that much time on tests.
Project day 100. CTO: why isn't everything covered by automatic tests?7 -
"I'm almost done, I just need to write some tests"
Almost all fail
"Okay, maybe I need a few more days"4 -
a little confession: i've rarely used test suites in my projects (due to laziness and lack of time).
i've started a new project and now i HAD to write tests in order to make my PM happy.
Then i had to refactor a lot of code.
IT WAS SO EASY WITH TESTS.
I WAS A FOOL.
STUPID PAST ME, STUPID!5 -
Unit tests fail.
Re-ran it again without looking at details.
Unit tests pass now.
What. Why?!
Now I can't sleep at night.6 -
I love TDD.
It's so relaxing to know that your fix didn't fuck up anything else when the tests pass. -
A while back I feel asleep on the couch on the day of the state of the union address.
My deadass mind heard someone asking what the "state of the unit tests" was and I leaped up and said "there aren't any! i'm sorry, it's only a small project anyway".
Thank god no one else was there... 😂 -
Boss coding.
Boss not fan of tests at all.
"Hey I'm doing all of tests" - boss to me.
"Cool, are they automated? Or do you want me to implement'em?" - me to him
[long speech about why tests are irrelevant including "...once I tested, it is tested, we dont need to have automated tests."] *im teaching you because you dont know voice*
Please, help meeee5 -
Out of necessity (or rather: lack of support) I've been neglecting my test suite for the past ~month. Now that one of the beta versions of RSpec has better Rails 6 support, I can finally get back to writing tests. Yay!
I just merged staging into my testing branch, and it's now 344 commits ahead of origin! eep.
So, I've got lots of tests to write. yay.random root loves her tests test suite yay! i didn't break anything! rspec root talks in third person in the tags surprise!3 -
Do you ever have those weeks where you have to fix a bug, then uncover another bug then another then another. Then you realise some functionality is completely missing. You write tests to cover your bug fixes and new functionality. Then you realise tests are broken with your fixes and you have no idea why. Then you get so frustrated you start making silly mistakes. Then your debugger starts playing up.... Yeah that's been my week.5
-
Half way through a 2 hour deployment, and a fucking test fails.
Yes, it takes 2+hours to run the tests.
Rerun in test environment: pass
Rerun in prod: pass
Rerun changed test in prod: fail..
Why, why you got to hate me for?
I love it when production is the place where config gets changed.rant tests are good multi environment changes tests can go fuck off right now tests save lives inconsistencies hurt5 -
A discussion about writing tests for frontend applications.
Context: my frontend coworkers don't write tests, at all. Yeah, really. Our testing process is very manual. We test manually when developing. We test manually when reviewing code. After merging, the application is deployed to a staging server and the design team does a QA Sprint. Lots of manual testing and some bugs still crawl by.
So I decided to start pushing my coworkers to start writing tests. One of the reasons I constantly hear them say to not write tests in the frontend is: "It's not worth the time, because design keeps changing, which means we have to take time to fix the tests. Time that we usually don't have."
I've been thinking about this a lot and it seems to me that this is more related to bad tests than to tests in general.
Tests should not break with design changes (small changes at least). They should test funcionality, not how things look. A form should not break if the submit button's style changes, so why should its tests fail? I also think that tests help save time, as they prevent some back and forth because of bugs.
Writing good tests is the hard part. Tests that cover what's really important and aren't frail and break with things that shouldn't break them. What (and how) should we test? And what shouldn't be tested?
Writing them fast is another hard thing. Are you doing it right if they take more time to write than the actual code?
What do you think about this? Do you write tests for your frontend applications? What do you test? How much time do you spend writing tests? What are your testing tools/frameworks?6 -
You don’t appreciate how large a project really is until you have to write tests cases for QA, to cover most work flows.
God this is mind numbing, only half way there... I think 😰3 -
In the last one and a half days I optimized our Angular UnitTests. There‘re written with Karma and Jasmine. Before the optimization they needed ten minutes for around 400 tests. Now the same tests are executed in 12 seconds.4
-
I love it to maintain old unit tests which were not executed for about 5 years. 2/197 are green (╯ ͠° ͟ʖ ͡°)╯┻━┻4
-
Once during a standup, I mentioned that I needed to fix some unit tests before the build would be ready. Our tester then said "no time for tests, we need the build now". That was a dark day.
-
I just wrote 80+ lines of tests for a 30 line module and I was really mad at myself for wasting my time like that, until I remembered that while writing those tests I did actually catch several really tricky bugs and it didn't even take that long.5
-
In my team, unit tests are called so, because every Dev is a 'unit' who manually tests their own code...
-
21 lines of business logic (including whitespace and comments)
9 lines of build config
386 lines of tests (and tests for the tests)9 -
When you finally see a series of ✓'s across all tests - today is a good day!
Now to write a whole bunch more that......, that dickhead past @C0D4 didn't do.10 -
Pipeline time!
Ubuntu: 100% tests, 367/367 tests succeed
MacOS: 93% tests, 330/367 tests succeed
Windows: 71%, 285/367 tests succeed
Time to boot up a windows vm...
(these numbers are not accurate)5 -
"Coding se darr nahi lagta Sahab, Unit Tests likhne se lagta"
"Coding doesn't scare me Sir, writing Unit Tests does"
As a fresher, UTs scare me.5 -
First Rant here.
So I was working on some integration test issues when I found this by accident made by a professional level SW engineer:
@Test
public void testMethod() throws ApiException {
Response res = null;
try {
res = serviceToTest.callMethod();
} catch(Exception e) {
assertNull(res);
}
}
Was wondering why tests were being green after some code changes I've made cuz tests could have not been green afterwards.
Together with a senior (I'm also professional only) I've tried to explain him for a good 1-2hrs why this code is useless and he still did it. Good thing there are no errors in the real implementation from him after fixing the tests as it's code freeze here and we are having go live in a few days 🙃
Also luckily he isn't working on our code anymore and has only been doing so for a few weeks.
Wasted a day with it and gonna check all of his code now before I run in the next surprise.1 -
How to force your self to write unit tests for your personal projects:
1. Go to a public place
2. Forget to bring your phone cable & never install a simulator because you are lazy af
3. Profit!4 -
Maybe in special dedication to @kiki.
I cut the unit tests down in LOC size by roughly 50 - 60 % in most projects.
It's really easy once one sees unit tests not as a dunking pile of copy pasta wild west, but rather as a code base that needs architecture and design.
Some extensions, some annotations, some good old helper classes.
Pooooof.
Why I did this? ...
Because it's fucking annoying when you read a PR with tests and need a fucking diff tool to spot the difference between two tests cause they're 80 % the same.
Yeah. Thx for giving me brain cramps, motherducker.
I'm not an expert in unit tests, but if all test codebases look like the "usual stuff" in our projects...
It's no wonder bugs exist...10 -
I had no idea of how to implement the logic of a ticket. That's why I started with creating some unit tests that failed. Then I continued working until they all passed.
So it works now.
I have still no idea of how I implemented the logic.3 -
Am I the only one who gets extremely nervous the night before an interview as that technical test can encompass the entire academic field of CS. I'm just worried I'll forget the difference between a clustered and non-clustered index or fail to convey the difference between TDD and BDD.
I'm ten years in to my career now, so I 'should' know my stuff. I've produced the tests my self, hired other devs, but I still feel the nerves.8 -
Do anybody here work with a codebase that actually has tests?
Or at the very least, the codebase has a domain layer, rather than puking lines of code randomly in the controller?
Am I trying to find an unicorn?7 -
Boss: "we're going to take over a project from another company. that's what we know so far - any other questions?"
Me: "do we get the history (svn/git) or just current source? unit tests?"
Other company: "no history for you. no unit tests - app was only tested manually"
Me: *sigh* :'(3 -
> Run 'All Tests' with Coverage
No tests failing
Coverage >95%
Hell yeah! I've tasted TDD and I don't want to look back!2 -
Getting beaten up over the quality of an app i'm working on with 6 interns. We have a bunch of unit tests, was shocked to see so many issues ... until I looked at the tests.
A function returning a non-optional array has 1 check ... that the return value is not nil ... fml3 -
IHateForALiving: gentlemen, my unit tests are randomly falling. Sometimes the login procedure just fails for no apparent reason, did any of you encounter this problem?
The very fucking smart colleague®: DID YOU REMEMBER TO PLACE YOUR AUTHORIZATION HEADER
Of course
The authorization header.
To fucking log in.
Because you have to be logged in before you can log in.
That's the standard, of course.3 -
I'm finally writing unit tests consistently thanks to a simple file organization decision.
I'm not doing pure TDD, but at least I'm writing the tests immediately after writing a module, and I make sure they run ok.
What I'm doing is Instead of putting the test files in a "tests" dir at the root of the project, I have the tests right next to the source code.
So if I have a dog.x file, I also have a dog.test.x file next to it.
I'm not inventing gunpowder here. I've seen several people do this.
But it's something that is not generally made a default or advised to do.
Like I said; test frameworks in general go with the classic "tests" dir.
But for me this is day and night in whether I write the tests or not.
Which makes sense. Imagine the classic scenario of the "tests" dir, and you just created a file deep into a hierarchy, let's say src/lib/console/windows/dog.x
This means that if you want to write tests for that, you need to make sure the hierarchy tests/lib/console/windows/dog.test.x exists
If the test file already exists, but you want to access both files, you need to traverse deep for each.
Also, it's actually harder to keep track which files have unit tests and which do not.
Meanwhile, if the test files are next to the source, all these problems disappear.
That doesn't mean there are no other challenges with testing, like testing untestable things, like system calls or http requests, but there are ways to deal with that. -
Employer: Hey, we are moving an API update live tomorrow morning that could affect our apps. Can you regression test the apps to make sure they all work?
Me: The API team is pushing code overtop of live endpoints that can break them?
Employer: Yes, we need the updates to work with a new product we are developing.
Me: And nobody thought about versioning these endpoints so we guarantee uptime on all existing services using them now?
Employer: We looked at that but it cost extra and required us to use the cloud solution so we don’t use versioning.
Me: Okkk… I also take it that the API’s don’t have integration tests written?
Employer: What are integration tests? Are unit tests the same thing?
Me: No, so when do I need to regression test all 7 production apps?
Employer: The API’s are moving to production at 4am and we need it signed off by 7am.
Me: I only have 3 hours to regression test 7 production apps at 4am? Each app, if I just skim over them, would take me 2 hours each. I will do my best but that’s a very short time to ensure complete functionality.
Employer: Don’t you have unit tests?1 -
Just a thought.
If your project has good coverage with tests, it should be possible to develop an algorithm that recreates your production code entirely from tests.
Just look at IntelliJ - its autosuggestions on missing properties/methods are 99% times correct - I only need to hit that ENTER button. Add some AI to recreate some algorithms and there you go - you can use your tests as both: code specs and a part of QA.
Any takers for the next AI project? :)4 -
I know I'm writing the correct integration tests when each one I add uncovers a new bug.
Still, it would be nice if just one of them passed first time.1 -
The "unit" in unit test does not mean your ENTIRE APPLICATION. Ever heard of scope!?
I am amazed how often people write overblown test setups, mock hundreds of unrelated services, just to test one tiny bit of logic.
That bit of logic could have been a pure function.
For that pure function you could write a dead simple unit test. Given that input, I expect that output. Nothing more, nothing less. (It helps even more if the pure functions only accepts primitives, like string and numbers, or very simple immutable value objects).
No I don't care that the service is used by another service, as your mocked interaction also doesn't test the service as a whole but you just assume the happy case most of the time anyway. You want to test the entire application? Let's not use unit tests for that but let's use a different kind of test for that (integration test, functional tests, e2e-tests).
If you write code in a way that easily allows for unit testing, your need to mock goes away.rant unit tests test all the things tests you are doing it wrong tdd testing don't mock me unit test1 -
When it finally clicked on how to write tests first and I could actually make code progress with it.2
-
Built a whole test suite around our Laravel app which has been pointed out to exec as slowing down CI and yielding no value to the user.
Arguing it’s ensuring something our users is using doesn’t accidentally break just gets brushed off as incompetence.
Oh well, I’ll just skip tests in CI and continue writing and running tests on my own as I don’t feel confident just cowboy fixing things.2 -
So yeah, apparently there is a drawback of covering your code with tests.
It becomes too scary to execute them because 1 of those 310 tests might fail. Seeing that not all the tests are green - that could be a nightmare.
Every time I run my tests I look away. There's just too much tension.. The more tests - the scarier6 -
Not a rant but I spent 30 minutes writing a fix for 2 integration tests while screen sharing. Ran the tests and they both pass first try, no exceptions, typos or silly mistakes. 2 additional unrelated tests also started passing. It felt good.2
-
Don't reuse your fixtures!
Each test case should be isolated. Don't ever think just because some function requires a similar input, it's safe to reuse it ALL OVER THE PLACE.
Why? Because someday, you want to change one functionality of one unit.
And you adapt your tests, fix your code, and suddenly, by changing one fixture, you break dozens if not hundreds of unrelated tests and now you have to clean up that mess.
It's even worse for functional tests with all those interwoven parts so that it becomes hard to reason about the scope of your tests when lacking proper documentation.
How I know? BECAUSE I AM CLEANING UP YOUR MESS RIGHT NOW!3 -
PSA: negate your tests and make sure they fail!
I have what I thought was a weird and slightly paranoid habit. When I write tests sometimes just as a sanity check negate the assertion to make sure the test fails and isn't a false positive. Almost always fails as expected.
But not today! Turns out I had forgotten to wrap my equality check in an assertion so it would always pass. It freaks me out to imagine pushing a test that always passes not just because it doesn't do its job, but could also obscure a bug and trick me into thinking it works differently than it does. Broken tests are the worst!
But it pays to be paranoid. -
I'm unmotivated and tired today. I'm just running tests in different branches to see what bug I can find... and since the testing take 5 minutes to complete, I just watch videos in between...9
-
When a bunch of unit tests start failing locally because the AWS secret key got rotated.
oh wait...
THOSE AREN’T UNIT TESTS!!!
Unit tests do not depend on any external system, that includes AWS...
AAARRGHHHHH1 -
Today I got a reply to a PR comment from a coworker literally stating that "it's not a good practice to add unit tests to hotfixes".
I can't, just can't. Left me speechless. Wonder where this guy gets his "good practices" from.7 -
Cold as fuck in my flat
i don't want to write these unit tests
RRRAAAAAAAAGSFGGDDFGFDSA SAFSA SVA11 -
Overengineering. Finding the right point between overdesign and no design at all. That's where fancy languages and unusual patterns being hit by real world problems, and you need to deal with all that utter mess you created being architecture astronaut. Isn't that funny how you realize that another fancy tool is fundamentally incompatible with the task you need to solve, and you realize it after a month of writing workarounds and hacks.
But on the other hand, duct tape slacking becomes a mess even quicker.
Not being able to promote projects. You may code the shit out of side project and still get zero response, absolutely no impact. That's why your side projects often becomes abandoned.
Oversleeping. You thought tomorrow was productive day, but you wake up oversleeped, your head aches, your mind is not clear and you be like "fuck that, I'm staying in bed watching memes all day". But there's job that has to be done, and that bothers you.
Writing tests. Oh, words can't describe how much I hate writing tests, any kind of. I tried testing so many times in high school, at university, even at production, but it seems like my mind is just doesn't accept it. I know that testing is fundamentally important, but my mind collapses every time I try to write a single fucking test, resulting in terrible headache. I don't know why it's like that, but it is, and I better repl the shit out of pure function than write fucking tests. -
I'm about to lose my freaking mind on intellij. Ran my tests yesterday and everything was good. I added a new method and a new test case today and suddenly no tests are found. Well they didn't go anywhere!! "Class not found, empty test suite" ... Lies! I've been messing with configurations for over an hour now. I just want to run my tests...1
-
Yesterday my tests caught more typos in copy/paste test cases than in actual logic.
'twas was a decent day.2 -
There is some gratification in writing tests and finding corner case flaws in your code. Don't worry past me, present me's tests got your back.2
-
Tests are failing successfully. Tests are working correctly. Maybe tests are failing but for incorrect reasons. Test checkers are failing as well but are they failing correctly? The checker testers are failing too. Checking the test checker tester tests.4
-
probably every time I see my tests failing.
Each time I am writing tests I'm convincing myself "it's an investment", "spend 2 hours now to save 2 days later", "unit-tests are good".
And each time I'm chasing away ideas like "perhaps they are right, perhaps writing unit tests is a waste of time..", "this code is simple, it should ever break - why test it??", "In the 2 hours I'll spend writing those UT I could build another feature"
Yes, it is terribly annoying to write tests, especially after writing the production code (code-first approach). Why test code that you know works, right?
But after a few weeks, months or years, when the time comes to change your feature: enhance it, refactor it, build an integration with/from it, etc, I feel like a child who found a forgotten favourite candy in his pocket when I see my tests failing.
It means I did a very good job writing them
It means it was not a waste of time
it means these tests will now save me hours or days of trial-and-error change→compile→deploy→test cycles.
So yeah, whenever I see my tests fail, I feel warm and fussy inside :)3 -
You may know I love to hate tests. Well not the tests actually, what I hate is the TDD culture.
DBMS schema in my app dictates a key can either have a value, or be omitted - it can't be null, and all queries are written with that in mind (also they're checked compile-time against schema). But tester failed to mock schema validation, inserted a bunch of null keys with mock data, actually wrote assertions to check those keys are null (even though they never should be), and wanted me to add "or null" to my "exists" queries.
No, we don't need more tests, and you're not smart with your "edge cases" argument. DBMS and compiler ensure those null values can never exists in our DB, and they're already well tested by their developers. We need you to stop relying on TDD so much you forget about the practical purpose of the code, and to occasionally break from the whole theoretical independent tests to make sure your testing actually aligns with third-party services some code uses.
And no, we don't need more tests to test your mocks, and tests to test those test, and yo dawg, I heard ...5 -
"Manual testing is often quick and easy and satisfying – you can directly test your application, one can see the results immediately on your screen, and one can interact with the application “for real”, instead of in the sometimes-awkward scripted/mocked mode of unit tests. It’s a very natural instinct.
However, it’s also largely-wasted effort! A manual test only verifies the current state of the code base. As soon as you make a change, you’ve started to invalidate the results. If, however, you take the effort to encode the test in code as an automated test, it continues to be valid indefinitely into the future."
https://blog.nelhage.com/2016/12/... -
Noobie moment with spring, wondering how the fuck to get unit tests to work in spring... might help if I put them in the tests folder...2
-
my coworker just disabled the unit tests in the build process
without telling anybody and without comment in the log
I was happy that my code worked then it was a little bit fishy that the build was so fast
I am so angry now and of course I need to fix the tests as well2 -
Working on a project with tests is so nice.
I love tests. Well, I hate making them, but now refactoring is so easy :] -
Too much technical debt
Write more unit tests
Unit tests failing, the code will be right so change the tests to pass
Too many unit tests to maintain, they look a lot like technical debt
Remove unit tests to reduce maintenance overhead -
Some of my co-workers are so fucking dumb. Their thought process....
Let's re-run tests that are currently failing over and over until it works
😡
like bitch....fix it then run it! don't just run shit over and over to make yourself look busy.1 -
I've finished the knowledge tests at the local DevJobCon and I got the following question on the easy part of the Java session:
Which of the following is NOT a Java IDE:
a) Eclipse
b) Netbeans
c) IntelliJ IDEA
d) Notepad++
😆6 -
Not writing tests for your code is like leaving it unguided in the hands of future Devs who gonna just change something and break the core logic and there won't be any regression test to run and check the integrity.
-
"Could you help on project X and implement that straight forward feature?"
So I clone the repo. Run the tests in the main branch. 20 tests fail.
Yes, this will be fun and very simple ...2 -
After finnishing all functionality defined in koncept our boss said that we should write some unit tests.
Wrote first one and already found 2 bugs.
I guess we should start with tests earlier 😅😷3 -
Holy. Shit. Tests. I am testing. All week. Nothing but tests. I am one with the spec. You know what I realised today? Tests are a bit like life. Life is just one big spec suite that takes 75 years to run. Except there's no prod environment at the end of the DMT tunnel waiting for our green pass docket to say 'take me Lucifer, you absolute visionary: I'm ready'. We're all just a spec with no application. We're doomed. Nothing matters. I need to lie down4
-
That joy of finally having them all passed.
I had stupid mistakes like: insertNewItem, but inside I use update T_T
project still fairly new, but this time I decided to write unit tests as I go instead of delaying till the end and writing nothing lol -
Killing people is bad. But, there should be a law to allow killing people who don't write proper unit tests for their code. And also those "team leaders" who approve and merge code without unit tests.
Little backstory. Starts with a question.
What is the most critical part of a quoting tool (tool for resellers to set discounts and margins and create quotations)? The calculations, right?
If one formula is incorrect in one use case, people lose real money. This is the component which the user should be able to trust 100%. Right?
Okay. So this team was supposed to create a calculation engine to support all these calculations. The development was done, and the system was given to the QA team. For the last two months, the QA team finds bugs and assigns those to the development team and the development team fix those and assigns it back to the QA team. But then the QA team realizes that something else has been broken, a different calculation.
Upon investigation, today, I found out that the developers did not write a single unit test for the entire engine. There are at least 2000 different test cases involving the formulas and the QA team was doing all of that manually.
Now, Our continuous integration tool mandates coverage of 75%. What the developer did was to write a dummy test case, so that the entire code was covered.
I really really really really really think that developers should write unit tests, and proper unit tests, for each of the code lines (or, “logical blocks of code”) they write.20 -
That emotional rollercoaster when you refactor a huge mess and finally there are no more compile errors in it. But there are still endless broken tests to fix :(
-
Actually, it happened just before my current holidays.
I had prepared a whole system to feed and use a machine learning model. My colleague and some others had been working on a great thing, all encapsulated, all abstracted for my system.
My last day at the office, they had it ready.
I install their thing, load one model and launch one dummy prediction: error. I try with other input data: error
I try debugging a bit more, errors all the way. Knowing them, I asked if they wrote some unit tests.
"Sure we did"
I find the tests, yes there are some. And I notice:
"Hey, I see that in all your tests, you're making more than one prediction at a time (=aka using a matrix with more than one row)
- yeah, and it work fine
- in the project, we're doing one prediction at a time, did you try it with one prediction?"
He tries: error, that was totally what I said.
I started ranting on loosing the scope of the project, why we do tests in the first place.
Then, I grabbed my coat, said "see you in one week" and let them rework their code.
I was so angry at them, it seemed so basic to just check that 👹 -
tests? ain't nobody got time foh dat. my brain already does all the job. it assumes and says to myself "all tests passed ✅" whenever i make quick changes
i like to live dangerously 😂1 -
Finally starting to write unit tests for this Java library I'm working on, and I'm wondering why I didn't do this sooner.4
-
Writing a small scale Ecommerce site for a friend. He keeps asking why I am writing tests for it all the time...some of us have standards3
-
Write code. Write tests. Everything passes and you go home happy. Come to work next morning, run tests again just to be sure. Everything fails.1
-
I've been compiling the project for about 5 hours now, still no successful build due to bad tests generating intermittent test failures...
All I wanted to do was to release the web project to the customer not fucking wrestle Cthulhu!
The worst part is that the release is set up so that you need to release the entire project internally before you can release one part. -
I really need to introduce unit tests.
Btw the module is meant for internal use and the readme is more for eventual collaborators than the general public -
First thing Wednesday morning, fired up the macbook, opened vs code, ran the same unit tests that were passing last night, 1 failure! FML.
For some reason an Angular form that was valid with the same data last night isn't this morning. Probably some crappy date issue in the mock data1 -
When a senior programmer told you they're done implementing the feature but don't know how to write the unit tests1
-
Always always always always always keep writing tests as you implement features. TDD is good thing but not necessary but tests are really necessary. I thought I'll write tests later now the code is so tightly coupled I can test things independently. 😑😑
-
I had an interesting mystery the other day. I work in the UK, but I'm working remotely from the US for a while. First day, I made some changes, ran the tests and they failed. Weird part was the failing test was for a component I hadn't touched. I took a closer look, and realized it was a date off by several hours. The test was checking that a passed in date appears in the output. But it was creating the date by parsing a string. The library I was using defaults to local time, but the component uses UTC. So, I had inadvertently created a unit test that only passes when run from UTC. But I had never noticed before because my work is in that timezone. Yikes!
-
Me 🤗"Since you know the domain far better than me, can I ask you to help me understand if I managed to cover all the edge cases with these UNIT TESTS?
😒" no no no, you don't need to check for those cases, you already do that in your code"
🤗 "I'm sorry, I must have explained myself badly. I have written these UNIT TESTS exactly to ... TEST if those CHECKS in my code work and what I need is you to tell me if there are additional cases ..."
😫"but you don't need to!!! You already have that logic in your code"
😐😵☠ 🦍💊🔫🔪"you know what? I'm gonna give them a second look. Thanks"
And then I moonwalked out of the room -
I'm so sick of "senior/lead" developers pretending they know how to write tests and ending up with these unmaintainable test suites, full of repetitions and incomprehensible assertions.
You should take some time to learn from your mistakes instead of just continuing to write the same shitty tests as usual!!!
Every time I arrive at a new team I spend weeks just trying to understand the test suites for what should be fairly SIMPLE applications!
UNIT TESTS SHOULD TEST UNITS OF CODE!
If your unit test tests seem to be repetitive, they are not unit tests. Repetition is expected in integration tests, but that is why those are usually DATA DRIVEN tests!!!14 -
Non-devs will never understand the satisfaction when you see your tests run successfully on GitLab for the first time. (Last course at university and we are supposed to do TDD for the first time. )2
-
Me at the beginning of the project: I should start by writing tests
Me after a couple of days: No time to write tests! GOTTA WRITE THAT CODE
Me now: Oh, yes, I should have written those tests at the beginning2 -
Working on a selenium test suite for a large web app. Nightly tests currently take 3h to finish. At what point do nightly tests become weekly tests??5
-
Test A succeeds when run solo. Test A fails when run in conjunction with Test B. Obviously, some kind of messy state that isn't isolated per test.
I realize what it is, so I add a new feature to address it.
Test still fails, it had nothing to do with that.
I finally realize what it was. One liner fix.
Yay for a new (useless?) feature that isn't getting backed out. -
When you write a new project using TDD and your colleague who isn't in to it make all unit tests practically fail and also breaks code style tests and doesn't give a flying monkeys.
His excuse is if you write tests what will test the tests -.-
What would your reaction be to that?2 -
What the fucking fuck. Arquillian you piece of shit.
I have a service that needs to go to production soon, it contains Arquillian tests. The tests work locally but not when going through our new Jenkins pipeline. The error message simply says: "Could not start Arquillian container".
Well fuck you too.
After 3 fucking days of rewriting configs, changing up things and I dont know what else I did, I stubled upon the most hidden error message in the history of error messages, a small little line that says "Could not find or load main class ".
Those 2 spaces are intentional btw, because the fucking error was that when starting arquillian and reading the config there was A FUCKING SPACE too much in my JVM arguments. This piece of shit iterpreted it as my FUCKING MAIN CLASS. Whhhhyyyyy, whhhyyyy. Who the fuck... AAAAAAAAAHHH
Btw I snuck myself on devrant a few weeks back and managed to get my 100++ today. Really love this place 😊1 -
Build test project in VS, all tests are visible in test explorer.
Make a trivial change and build, all tests disappear.
Restart VS and rebuild, all tests visible.
Make another trivial change and build, all tests disappear.
I'm beginning to think VS isn't very good.5 -
Me to co-worker: The tests are failing because you didn't format your code before submitting your PR
-Co-worker changes the test command to run the format command just before running the tests-
Co-worker: The tests are passing now!
-facepalm- -
JUnit 5 and Mockito are so cool! Writing tests is so much fun! Having tests is a blessing! 👉 WRITE TESTS 👈
-
Hennies I need your assistance!
My boss has put me in charge (wow yes I was surprised too) of figuring out what a good solution to our current testing nightmare would be. Therefore my questions for you are:
What kind of testing strategy do you work with at your job? Do you use any tools for it? How's the division of unit tests/service tests and/or UI tests?
I'd really appreciate you guys' input on what works (and what doesn't, in case you're living a nightmare with testing daily)10 -
Disclaimer: I am an assclown who makes cobbles shit together and doesn't have a strong/real foundational understanding in the shit I deal with.
So does anybody actually write their tests before they write their code? I see the term TDD (test driven development) bandied around everywhere.
I don't know what the fuck I'm doing or what the solution will be, nor am I confident in it until I've manually tested it seems to be working.
Then I usually write the automated tests if they are easy to do so.
i.e. I won't know what/how to test the thing.....until I make the damn thing
Is this a case of 'git gud' and have the problem "presolved" in your head, before you work on it such that you can already write tests first?
Or is this a case of "aGilE", where everybody says they're agile, maybe does a little bit of scrum (just the pieces they like/find useful, not the entire thing in a dogmatic/religious way), and possibly has never heard of the manifesto https://agilemanifesto.org/12 -
mvn clean install: all tests pass
run all tests in IntelliJ: the same 6 tests fail every time
run those 6 tests in IntelliJ: they pass
-_-4 -
Boss wanted our AES implemented to use an Initialization Vector. I changed the implementation to add an IV and all the tests passed on the first try!
I changed the implementation to fail just to make sure I wasn't getting false positives. -
Load tests:
I'm used to do load tests in Visual Studio where it gives which line is exactly your bottleneck. But now I'm using VS Code (visual studio requires enterprise license for load tests :\ no longer have one)
Anyways long story short, what are the best practices for load tests? For me what I'm testing is how much can a given hardware specs handle and when test fails I go back and check if code can be optimized, is this the correct way to do this?7 -
My company never used unit tests. And i would love to educate but i do not know how to unit test properly. I always en up with: if i want to properly test all ins and outs of this class's + operator. I need to add checks for positive number, negative numbers, nan, infinites, nulls etc. Etc. It needs so many tests for something so stupidly simple, that i don't see a way to motivate people to use it.
Am i missing something? Is there a guideline for "ok coverage"? Is testing just that much work and is that why nobody cares until it is too late?
I have been reading a book about working with legacy code. But still i got no answers. Halp!7 -
Today started good, the latest PR merged in took our Flutter app to 66% coverage with 1009 tests.
This means we also have 1001 more tests than our companies other apps combined. 🤣 -
FUCK YOU JENKINS
The tests work everywhere just not for you
It worked before and I DID NOT CHANGE ANYTHING FOR THIS TEST TO FAIL
FUUUUUUUCK5 -
I read: "Don't change your implementation to do tests"
Then I read: "If it's too hard to test, your implementation is too complex"
Then we can get into test terminology itself, which is its own mess:
http://xunitpatterns.com/Mocks,%20F...
sheesh, if you thought the whole javascript / framework / web ecosystem always feels immature and behind other areas of software, i'm about to argue that testing patterns are even further behind8 -
TMW you want to introduce a big feature that will require you to refactor the existing code, but you don't have to worry about breaking the latter since you have tons of unit tests backing you up.2
-
You know you're tired when you're setting up unit tests and you make more mistakes in setting up the tests than in the actual code.
-
Async tests are seriously fucking fragile there has to be something I'm missing here this is way too unreliable4
-
My boss has been pretty insistent on us writing good tests (which I wholeheartedly agree with) for our new project, and being the less-experienced junior that I am, asked if we could get some guidance or a demonstration.
Took two weeks, but I finally got it said guidance... by opening a pull request with tests that weren't absolutely perfect.1 -
I started a new job, got through on-boarding and took my first ticket. Made my modification to the code base and the tests fail .. each time I run them .. on different tests .. randomly.
What the hell have I gotten myself into?3 -
React Native testing is hair pulling.
Every test needs to have 100 different mocks in place and there are: 3 different methods to mock a function (mock, mockImplementation, and fn), 3 different types of query methods to get elements (get, find, and query), and 5 different selectors to query on (accessibility label, testId, accessibility hint, accessibility value, etc.)
And after reading all this, being diligent and learning the difference between stupid, synonymously-named functions which have wildly different side effects like "getByA11yHint" and "findByA11yHint" (ugh...), after all that, you write out a test with all the appropriate mocks and you want to do something simple and it beats you up all over again.
Button enabled or button disabled. Simple right? Logically the former is "expect(elem).toBeEnabled()" and the latter is "expect(elem).not.toBeEnabled()", right?
Wrong! You're an imbecile. Your tests will fail and never tell you that ".not.toBeEnabled()" and ".toBeDisabled()" don't do the same thing even though they look and sound exactly the same. Only the latter will work. The former makes all your tests fail. Where is this written in the docs? Nowhere?! Great!
👌😄🔫3 -
<Question>
I'm curious: For those of you who have tests running in CI pipelines at work:
How long does it take to run the tests, in relation to the system's size?
At my company, it's ~ 30 mins, testing 1M lines of code (750k SLOC) written in Java (85%) and JS (15%).7 -
When I study just to pass tests, I'm a bad student. When I write software to pass tests, I'm a good developer. 🤔
-
I. Fucking. Hate. Tests.
I am writing a module according to a standard and this standard has a test suite. Awesome...this should make development go pretty smoothly especially since their human-readable "specification" is severely lacking.
I get the module passing most of the tests...however there are few I just can't get my module to pass, no matter what...well fuck.
I go digging deeper into the test cases, compare it to source code. What's this? The tests are fucking wrong. There are several other implementations that use this test suite, how the fuck have they not caught this?
Also come to find out, it is not possible to pass *all* the tests in the suite because some are for older versions that have different functionality.
Got to love a test suite that is incorrect and can't be passed 100%
Maybe they need tests to make sure the tests are working correctly.3 -
Aiming for 90%, barely managing 60% ever.
From marks in school tests to code coverage in apps, the reality remains the same. -
continuation of "testing is not needed" series
https://devrant.com/rants/4407958
a second former colleague (which works as backend dev) was seeking frontender, and remembered about the React frontender we both worked with.
I decided to warn him:
> *Giggles* According to his words, front is not like back. Git and testing aren't required there.
I received next replies:
> actually I don't need tests as well
> I did not write them all this time
> I have testers in a team for that, which do the testing for me
> I think I'll need it in cv though.
My comments:
I am trying to imagine their code... architecture, and I am a bit scarried to see how it looks like, are you?3 -
Why are there so many testing framworks for JavaScript? Jasmine, mocha, buster ... and for spies, stubs and mocks, there is sinon and for assertions, there is chai. And oh you can record entire external api calls with nock and whatever else I forgot. I am a bit overwhelmed by this overambundancy of libraries. Writing tests is supposed to be easy.2
-
Write meaningful unit tests! Unit tests are like micro documentation for your code that you can validate in seconds.3
-
What's the most inane excuse you heard for either a developer or management to not write tests?
I have endured these:
Management:
1) The project is fire and forget. It won't need tests.
2) It's a prototype. It won't go live.
3) Writing tests takes longer than without writing tests. You know how to code, don't you?
Developer:
1) I didn't have the time.
2) It was such a trivial method.
3) It's not mockable.5 -
For completely nonsensical projects I propose a new metric. Instead of counting how much code is covered with tests, I propose to count how many tests are actually testing the code. They really write more tests than code nowadays3
-
New project, make a simple change, a load of tests fail, stash changes to see if they ever passed, rerun tests: they pass ... rubbish must have been something i did. unstash changes, rerun tests to check the details: they pass ... walk away slowly
-
Fixed obvious bugs.
Tests started to fail.
All error messages read similarly—“Feature XXX contains an obvious bug blah blah blah. It’s supposed to fail, but it’s not.”
F____!!!!!2 -
I'm using typescript and run mocha acceptance tests. I was confused as to why my tests were failing on the Jenkins albeit they passed locally just fine.
I couldn't find the error. Just after making a pause, implementing something else, I realized what the problem was:
As I renamed a folder from `fixtures` to `tapes` my test run on the Jenkins suddenly claimed to not find the files in `fixtures`. Yet in my code base there was no occurrence of the string `fixtures` anymore and then it hit me like a brick wall:
I have old transpiled files in my outDir, the `dist` folder on the jenkins! Locally, I make sure to run `git clean -fd` once in a while, so I never was hit by it it locally. Yet my jenkins had really old files in the `dist` folder. And just running `rm dist/* && tsc` fixed the entire ordeal.
Well, JavaScript is so 2012 and typescript is the new shit, yet transpiling the code can leave to some quite strong headaches.1 -
Does anyone have any tips on how to test a software developer for problem-solving skills and learning capabilities?
I don't really care if the developer knows frameworks and languages XYZ. I want to know if he/she can learn those things, knows how to find answers to problems and actually tries to do a good job. Those seem the most valuable skills to me.
Any suggestions?5 -
Need help in Unit Tests,
I've reached a point where tests randomly fail, but if I run that test alone it never failed.
I do have lots of shared data between test functions of the same test class.
What options do I have?
1. Make each function responsible of seeding data into InMemory database?
2. ??? (I don't know what else I can do)
Any help is great :)18 -
In my company we are constricted to have 100% of f̶a̶k̶e̶ coverage with unit test.
Obviously the test suites are not performing and it takes more than 8 minutes to run 3335 tests.
I know that what I'm going to say is super mainstream but there is nothing comparable to the relief that comes from seeing all tests in green after you did a lot of small changes around the code on Friday.4 -
What do you guys use to write unit tests in C? I look at some libs such as check, cmocka, gtest etc, but they all seem like way more than I need. Also, I have a hard time to separate test files and source code files (directory structure wise).
Any recommendations?5 -
Looking through Java tests, cause I need to pass one for job. And every one of them has a question like:
What's the result of:
boolean b = 42 >= 1024;
if (b = true) System.out.print(1);
else System.out.print(2);
And each time I answer like there is (b == true) and not (b = true).
Cause no one in real life would write = in if statement. Why do they put such question in each and every test.1 -
The logic in a method reflected a truth table not obvious to understand. The first time I implemented tests for coverage as I didn't trust anybody to remember and understand the logic after a few weeks.1
-
Two real reasons people write unit tests:
- mommy’s boy can’t even fart without mommy’s approval, but instead of mommy, there are unit tests now
- Stockholm syndrome47 -
Currently in our 4th cycle of manual regression testing for a release and still finding bugs. Automated tests? What are those? That sounds an awful lot like it would take time to implement. Time that could be spent fixing the bugs and getting the release out the door.
When release dates take priority over quality.... -
I'm an iOS developer and I cringe when I read job specs that require TDD or excessive unit testing. By excessive I mean demanding that unit tests need to written almost everywhere and using line coverage as a measure of success. I have many years of experience developing iOS apps in agencies and startups where I needed to be extremely time efficient while also keeping the code maintainable. And what I've learned is the importance of DRY, YAGNI and KISS over excessive unit testing. Sadly our industry has become obsessed with unit tests. I'm of the opinion that unit tests have their place, but integration and e2e tests have more value and should be prioritised, reserving unit tests for algorithmic code. Pushing for unit tests everywhere in my view is a ginormous waste of time that can't ever be repaid in quality, bug free code. Why? Because leads to making code testable through dependency injection and 'humble object' indirection layers, which increases the LoC and fragments code that would be easier to read over different classes. Add mocks, and together with the tests your LoC and complexity have tripled. 200% code size takes 200% the time to maintain. This time needs to be repaid - all this unit testing needs to save us 200% time in debugging or manual testing, which it doesn't unless you are an absolute rookie who writes the most terrible and buggy code imaginable, but if you're this terrible writing your production code, why should your tests be any better? It seems that especially big corporate shops love unit tests. Maybe they have enough money and resources to pay for all these hours wasted on unit tests. Maybe the developers can point their 10,000 unit tests when something goes wrong and say 'at least we tried'? Or maybe most developers don't know how to think and reason about their code before they type, and unit tests force them to do that?12
-
cleaning up resources in async tests in rust is... uhhh what the fuck honestly
just wat
wat
just forget about it I guess. ew.1 -
Tests, unit tests, integration tests, ui tests, tdd, bdd
I thought I was done with tests after school. Why, why you do this to me 😢😢😢4 -
When it turns out the 900 line unit test set up called another giant method which you need to dig through but it's labeled deprecated. O.o?4
-
Shallow() or To Mount()....shit react tests have been killing me. The issues on github have not been resolved. And our team lead has insisted on them even more. Haha they way I have been ditching them.
-
I really hate how steep the learning curve is for testing. I've been writing the same test for a week for a 150 line directive, and it's driving me fucking nuts. Nothing makes sense. No one in the office to help me. Only 10% of engineers here write any tests. I don't know what to do. Overnight they made it a rule that if you want to move up to the next level for software engineers, 80% of your code needs to have unit test coverage. It's just bullshit.3
-
Wanted to add a simple log entry when a model changes state in a certain way.
Unit tests pass, functional tests pass, manual tests through application GUI pass.
But for some fucking reason the single line logging call I added results in an error 500 when the application is accessed through a REST API.
Going to have a fun day tomorrow debugging this shit. -
Just spend two fucking days debugging a few methods in our program. I used unit tests to call those methods (don't want to navigate through the complete program workflow)...
Yeah, guess what: the test cleanup includes a fucking rollback transaction function. So NONE NADA ZERO FUCKING CHANGES WILL BE PERSISTED. Fuck me3 -
Recent posts from @kiki and others made me think about tests. So what are your 2 cents regarding integration tests?14
-
So I became a team leader ("promotion").
One of the team is a senior by title, but fuck he is just a refactoring machine. Seeks for architecture design in fucking everything. Even in fucking tests instead of just writing them he is inventing convoluted architectures and systems...
Fuuuuuuck - just write the fucking tests, no one gives a shit if you have a fucking factory in the test case! -
After 30 minutes of fixing the code I finally noticed that someone switched the position of "actual" and "expected" when writing unit tests.
-
Unit tests pass locally but fail on the pipeline. After 3rd re-queue, pipeline tests pass. I am so over this bloody week.11
-
Skipping jasmine tests- especially ones on partials (not the controller). Seriously, QA has automated test suites to test UI functionality. If it takes 30 mins to write the code and 3 hours to write the tests... it may just not be worth the effort when there already is automated testing.
Ugh I hate skipping them but you know how to test the UI? Use the UI. -
when you're the unlucky fuck and/or too stupid to get green builds so you get flamed when the flaky automated tests (from before your time, not written by you) rear their head and shit all over you
you then get flamed for not going out of your way for fixing them, as the team verbally agreed to do so, but very rarely if at all has anybody done so (it's not so easy trying to fix something when you don't have consistent steps to reproduce)1 -
Working on a multi-year college project, going through tests from previous team.
Every test is not working quite right. They're almost all intermittent failures.
The reason? Every single test class extends some test class, which usually extends from some primary test class.
That primary test class opens up their whole UI, and outside of their UI test package, the only thing that gets used is a variable named session (a string), which isn't even specific.
WHY THE FUCK WOULDN'T YOU JUST MAKE THE SESSION NAME STRING A VARIABLE IN THE TEST FILES YOU DUMB FUCKS
THE ARGUMENT VALIDATION TESTS DO NOT NEED TO OPEN THE UI, LET ALONE CREATE THE WHOLE FUCKING DATABASE JUST TO VALIDATE ARGUMENTS, WHICH YOU DO APPLICATION SIDE
(Also they made it so every session has their own tables as opposed to having session IDs. E.g., "person_sessionID1" and "person_sessionID2" exist.) -
I hate unit test. I hate testing by code.
I hate the idea to write code that tests code. And that u must update both when u add a feature. Like wtf.
Good debug mode with clear verbose and precise reporting tool and voila.
Drives me nuts thus trending shit.10 -
That moment when I realize that my project has a dependency written by a researcher with no tests whatsoever while I spent 2h today writing my tests.
-
Visual Studio's Test Explorer is a piece of shit.
Maybe the user wants to repeat the last test run without rebuilding? No can do. Maybe the user didn't add or remove any tests, but just needs to rebuild without running test discovery again? Nah. Maybe the user just needs to discover tests from THE ONLY ASSEMBLY WHICH WAS REBUILT? Too frickin' bad.
A 120-second turnaround (30 to build, 90 to discover) just to _start_ a test run is bloody atrocious. Especially when VS decides to run test discovery twice in a row for no given reason.
*sigh*...
I'd use ReSharper's runner, but unfortunately it isn't capable of running xUnit v2 tests when you've designated a custom XUnitTestFramework. -
Okay..
So, what do I have here?
A cross platform mobile app with NO unit tests.
😕
I have to write a big new feature from scratch. (Things can't go wrong, right?)
Started working on it, pointed out problems with the UI/UX designs. The design changed multiple times, still I thought I could finish it by the expected date. And, so I did.
The feature went through testing, and they found bugs. (Surprise...?)
It's already kinda scary to touch someone's code that has no unit tests and no comments. And I think, it's all the more difficult to not introduce bugs.
Also, had to work on the weekend to fix the bugs.
I had some good learnings here, but I'm not sure how I can prevent bugs without unit tests and proper feedback cycle. :/4 -
How to write tests for a scraping script cause the website dom may change at anytime so using a website is not an option while writing tests .4
-
semiRant
The debugging options in VSCodium for when working with golang have certain limitations on them that have made me start writing more tests inside of my codebase (s).
I find this both beautiful and frustrating at the same time since for 1 it has made me(no, forced me) to learn testing on the language as a primary thing rather than an afterthought (judge me all you want) and if this was added by design to force people into properly writing tests then BRAVO.
Well played Mr. Pike and Mr. Thompson, well fucking played you outstanding beautiful bastards. -
i'm spending my time,
watching the tests go by,
failing them all,
I stare at the wall,
hoping that you won't notice them too,
i'm spending my time -
Finish the story and all tests pass
*notification another merge request been approved
Pull changes build, all tests faill -
I really love JetBrains IDEs and I use them all day. However now the unit tests in the IDE are broken and cannot be run anymore. Please fix asap :( I can't work like this.2
-
Manual tests (the only way of testing within my team) fails one after the other.
The fault was a manual misconfiguration.
Why the fuck in 15 years since he got this job that test manager hasn't improved this?3 -
Anyone ever heard of robot framework? Its the biggest pile of shit i have ever seen! WHY THE FUCK CREATE A TEST FRAMEWORK FOR TESTERS WITHOUT REAL CODE AND JUST KEYWORDS WHEN ITS SO FUCKING COMPLICATED TO USE THAT NO FUCKING TESTER CAN DO ANYTHING WITHOUT HELP OF A DEVELOPER. this shit tests cost me hours each week to fix because every minor change breaks like a a dozend of tests... i dont rant often but everytime i have to fucking take a lool at that shit a start to boil...3
-
I just commented a test so the PR passes and the feature reaches next release; I can't fix it (Damn react testing library tests)
but after that, the linter failed for the same PR, so I just fixed it and did a git push -f
I guess once you cross the line you cannot come back
feel my pain1 -
What's the worst part about testing React components? Using the equivalent of fucking stone tools to do your component integration tests! We got errors with no context and errors with no stack trace, just spewing out bullshit! A sample:
The classic "Can't access .root on unmounted test renderer"
The unforgettable and ALWAYS visible "Warning: An update to YourShittyComponent inside a test was not wrapped in act(...)."
We do love it! -
The code passes the tests which i wrote for the code to pass so it must be fine. (These are only assert statements mind you)4
-
Spent the day migrating to a different mocking framework for our unit tests.
Still a few hours of work to do until they'll all compile.
After that, who knows what'll still need fixing.
Pouring myself a tall one. -
WHAT GOES AROUND COMES BACK AROUND
Overflooded with tickets about regressions, management finally gave in and instructed us to use integration tests again.
Who would have seen that one coming.
(at least half of these "regression tickets" were not regressions at all, but I'm not going to be the one spoiling the first time management actually makes the right call)1 -
Me: * Not having fun writing hundreds of tests/assertions for an API *
Also me: * Submitting changes without running my tests *
Production: * BROKEN *
RUN YOUR EFFING TESTS EVEN IF THE CHANGES ARE SMALL OR STRAIGHTFORWARD OR SIMPLE OR WHATEVER -
Management wants me to write e2e tests instead of unit tests. The problem is there are e2e but not a single unit test... I plan on refusing.
-
I have to mock an API for my tests. The mocks got so complicated, I basically have cloned the API at this point. Now I'm testing my mocks to make sure they work. I'm essentially writing tests for my tests. There's gotta be a better way to do this.2
-
Ever had to switch out a whole serializing layer in an API? Damn that's a lot of work :(
At least the 1952 tests are written well... -
Does anyone have any advice for making api integration tests data independent? We have a few hundred tests firing against our seed data and they all check for hard coded values. But the problem is that this means adjusting seed data is really really slow as you have to fix integration tests too, which can be thousands of lines of values needing to be corrected.
-
I dont see any advantage of TDD. I use integration tests and unit tests for very complicates modules.
Change my mind.5