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
Get a devDuck
Rubber duck debugging has never been so cute! Get your favorite coding language devDuck
Buy Now
-
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 -
Fuxk yeah! My code works! It's 2AM, I'm happy and there's no one around, so I wrote a poem :-P
What was once impossible,
Is now close to completion,
Thanks to my debug statements,
Which now await their deletion.31 -
When your colleagues have no tests for their code and tell you not to touch it, because it WORKS!
15 -
About 11 months I posted that my wife was pregnant. I now have upgraded to son 1.0. All without writing any tests!15
-
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...5 -
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 -
How to quit smoking as a developer, tutorial:
#1: You're only allowed to smoke when every unit test is passing.
#2: ???
#3: Profit5 -
Once I applied for a Java position and they sent me a a online test, user and password. When I first tried to log in, it gave me an java exception. I lost hours trying to figure out the exception , thinking it was the test :/5
-
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...1 -
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.6 -
"Trinidad And Tobago" changed their country name to "Trinidad & Tobago", and the .Net framework reflected that change.
So that's why this unit test is failing.
I GUESS BULLSHIT IS NOW INTERNATIONAL.2 -
You know how some people put those little badges in their readme files in GitHub?
Well, one of my team members didn't know how to make those work correctly, so they just plastered images of them to make our repo look good. In actuality we have no coverage, no testing, no nothing...
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
-
!dev && feelsbadman
I don't know what to think.
All I know is that I just went reaaaaal close to a disaster.
Friday morning, my "scariest" manager (as in, if you have to meet with him, it's usally for something serious) told me that he needed to see me on monday (so today) with the lead dev, the project manager and the dude who recruited me.
The meeting was like an arena of 4 vs 1, where they all 4 had problem with the work I do, as in I make a lot of small but stupid mistakes that wastes everyone's time. As an excuse, I suffer from sleep apnea so I wake up as tired I am when I go to sleep, and I snore loud as fuck. I've heard some records, it's not even human. (I'm 1m85-ish for 125 kg, it's BIG but with my morphology it's not like I'm a ball of fat)
Anyway. And since it's not the first time they're reproaching me this kind of stuff, they were all... really angry. Because I'm a nice guy, competent and all but not productive enough and easily distracted.
So, when the manager asked me to meet me, it was to fire me. However, during the lunch break, the lead dev found a solution: I get out of the current project I was in until this morning, and I write all the functional tests for all the projects, because they all lack quality and we sometimes deliver regresses.
They proposed me this in a way I could refuse, and I'd get fired because they had no other options. Obviously, I said yes, I'm not stupid enough to decline a possibilty to avoid a monstruous shitstorm that would have cut me my studies, the money for taxes, and a lot of fun to find a job as fast as possible.
But what surprised me the most is that they were genuinely glad I accepted, like, even though I made my shit ton of mistakes, they weren't pleased at all to get rid of me.
And in a way, I'm the one who won in this story, since I don't have to work with Drupal anymore, excepted to parse the website to write my tests, but my nightmare fuel is finally gone *.*
I don't know where to finish with this rant, but I needed to vent this whole thing, to write it somewhere so I can move forward.
I wish y'all a nice week.3 -
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 -
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 -
Why are Job interview tests so reliant on knowledge of the language's functions!
I dabble in a few languages and I don't bother learning all the basic functions of by heart...
Eg: len(str), str.length, str.Length, strlen(str)
why... because they are literally a 5 second Google. Unfortunately for us, this quick search isn't possible and I think it should be.
Another example of bad interviews is a coder with 37 years experience but was unable to get a job at Google (link: http://gwan.com/blog/20160405.html)
He was asked strict questions by someone who didn't know much about computers let alone programming. Unfortunately, since the interviewer wanted exact answers, the coder was unable to complete the interview. He answered all the questions validly and with depth but this was not written down on the interviewers sheet.
Do employers want people that have a good and broad knowledge of their field or people that know what they want them to know. It's getting ridiculous.9 -
I was with the train in Vienna already when suddenly I received an email that the test can't be held today because of technical problems 🙄
Now we have it next week when I also have to study for a maths test, do statistics exercises and exercises for database systems
Fml6 -
"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 -
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 -
I love TDD.
It's so relaxing to know that your fix didn't fuck up anything else when the tests pass.1 -
"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.)9 -
"I'm almost done, I just need to write some tests"
Almost all fail
"Okay, maybe I need a few more days"4 -
I fucking HATE testing JavaScript. It's such fucking bullshit. I've been struggling to test one simple functionality for multiple hours. It's probably one stupid thing I can't figure out, so I hope some sleep will grant me a fresh look tomorrow.
Also it's absolute bullshit the amount of libraries and dependencies you need to have to get some proper scalable tests going. Jasmine, Babel, ES2015, yarn/npm (because Jenkins is too fucking old to handle yarn). React, react test helpers, webpack. The list continues. FUCK OFF!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!6 -
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 -
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... 😂 -
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 -
Do you know that feeling when you finally have no more errors, but then you can't tell if the software actually does the right thing?
🤢
Wisdom of the day:
'No crashes' is not equivalent to 'it works'...5 -
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
-
In my team, unit tests are called so, because every Dev is a 'unit' who manually tests their own code...
-
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 -
-Management puts unrealistic deadline as usual-
_Tries his best but fails to deliver on time_
*Puts a clearly visible bug in code*
~Tester finds it and creates a issue~
*Solves the issue, wraps up the remaining things and closes the issue*
**Wakes up from dream, cuz he is the tester as well** -
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 -
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. -
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 -
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 -
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.4 -
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 -
Just did an internship test for Autodesk and came away from it with the conclusion that I'm really stupid.
May as well give up on my dreams.4 -
Those last couple of hours on a Friday afternoon in the office dragged out longer than the ending scene of part 3 of LOTR. Only I am pretty sure that the hobbits did not have circus music doodling in their heads while trying to write jest tests.10
-
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 -
Here's to actually being done with changes in the morning, a colleague requesting a lodash function call replaced by vanilla js, and my unit tests exploding as a result of the changes. Apparently lodash is far more forgiving than vanilla js about what you throw at it. That's my day gone. I need a drink. cheers!5
-
Not learning unit testing... I've heard so many good things about them, but I've never learned how to inple.e t and use them.
Maybe I can start now, can anyone point me in the write direction?5 -
Oh lovely. There's a fucking bug in my tests, which I can't fucking reproduce.
Hahaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 🙃 -
Today I wrote the most epic code.
The kind that breaks your brain, but when you're done with it you know it's time to go home and kick back coz you've done good.
It used recursion, did backflips to avoid unnecessary db calls, featured no code repitition. Hell I even commented the business rules it was following in there to explain what was happening.
I hope it works tomorrow when I test it 😂😂😂6 -
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 well3 -
!rant but wondering,
I'm doing Instrumented test for my android app, and wrote that code to check if the fragment loads data and click on first item and check if all is working as expected, am I doing it right?
Any help would be great :)
Warning: LIGHT theme ahead, room brightness is higher than my screen and I can't see shit in dark theme :\
10 -
Just found a unit test in a legacy project that is over 300 lines long, creates files on the server and multiple records in the database, then deletes them all. It takes over two minutes to run.
Madness5 -
If only they allow us to write unit test at work, its not that It is forbidden but we are not given time to do so :\
Done my test on my side project and now I can happily move to the next step.
Though I'd be happy if someone answers this:
1. When I have to execute functions by order, do I write all their code in one single function and divide them into regions (speaking of C# #reagion)
OR
2. I keep them split and implement the order attribute for XUnit?
My test case is basically just to make sure CRUD methods inside my repositories are working as expected, noting complex
5 -
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
-
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 -
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. -
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
-
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.2 -
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.5
-
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
-
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
-
"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/... -
Somehow, a contractor left with all our unit tests six months ago. I just inherited this project. It's 200kloc of Django spaghetti, and I have no unit tests.5
-
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.
-
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 👹 -
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 -
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 -
My matryoshka keeping me company, because of course when you are alone testing a last hour deployment. shit will happen
6 -
Assertequals("Fail","Fail") in the catch block.
Things developers do to bloat their test coverage at my organisation,
I am #stuckWithIdiots
Management sees green1 -
My tests were failing in laravel 5 on my app, so I ignored them but when I went and dug into the test it was made for the default laravel page.
-
How do you test unreachable code or part that is considered an edge case?
For example I catch exceptions in case IO failed and data was not written on database, but that only happens if hardware failure, or no disk space left, how do I mimic that?
I also have unreachable code for example, in one layer I fetch data (lets call it function x) and always return success result unless item not found I throw KeyNotFound exception. But in the calling function I handle the case of Status == Failed
Just in-case in the future I change function x and start returning failed status, so my logic already written but never reachable12 -
Looking at an old Java project, running java 1.6, test folder doesn't even exist and the "old but gold" java.utils.Date class is used throughout the whole thing. How do I initialise a new date again...? I actually just googled that :D At least the constructor parameters are named nicely... wait.. what...
1 -
Make a small contribution to a github project, with tests because that was one of the requirements set by the owner. Owner then comments why I've made a test for this change... well... Because you asked for it. Be consistent. Either write tests for all functionality or don't bother at all. Now I feel like I've wasted my time.
-
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 -
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 -
This is just a sweet little harmless block of code, why should I unit test it?
3 months later...
Bug in production : This is why. -
Couple of weeks ago I received a negative response about a code test I did for a front and position. They only said I was not a good fit.
Today, I received another email from them, asking me to do a test. I asked for clarification, and they said they are giving me a chance to redo the test.
Sounds weird, but I'll redo the test anyway. The task is to code a responsive page that consume an api. I'm using vue, sass, git, modular and semantic code. What else should I focus?
The deadline is in 36h.2 -
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.1 -
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!
-
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
-
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 promised to blow off unit tests, so here we go. Let’s talk about unit tests.
Why use them? So, unit testing connoisseurs outline two big purposes:
1. To keep application integrity,
2. To catch bugs.
Keeping app integrity is when your freshly hired developer implement something that potentially leads to the whole app failure, but unit test fails and tell you that newly added code is breaking the app.
Catching bugs is pretty much self explanatory. Just think about it – you have to actually write code that describes how to check up another code to catch bugs in it.
I personally hate unit tests. I can’t explain, but every time I forced myself to write them, I got vertigo and terrible headache to the end of the day. Trying to write some tests? Here you go, wooosh and you can’t work anymore. Go get some sleep if you can.
But I still needed my job to be done and it should have been done really well. So I started my research.
Recalling Steve McConnell’s and many other classy developers’ experience, there is only one decent solution that prevents bugs and inconsistencies at large scale – the specs. Developing the specs should be considered the task number one. With decent, robust specs, app is almost guaranteed to contain no bugs.
Let’s take a look at the piece of great spec. For example, imagine you have to implement validation logic. So you state that validation should be implemented with special validation functions and then you define what validation function is: a pure function that accepts a value and returns boolean: true if value is good, false otherwise.
With that in mind, it’s obvious that potentially present bugs can only be inside that pure functions. Our spec made implementing validation very easy and idiomatic, isolating potential bugs. As soon as validators are pure and simple, unit tests aren’t needed at all.
You know what? As your app scales, you’ll definitely need a spec, sooner or later. Growing up without spec leads to irreversible failure, your app will grow like cancerous cell does and it’ll be easier to just put it into trash and start up from scratch.
But specs have one major downside – it requires at least one enlightened developer with really great experience to create it. It can’t be done quickly, it’s a very costly and difficult process. That’s why making great software costs that much.
But what if you need an MVP right now?
Speaking of MVPs, you’ll have to go with simplest instruments possible. Throw away Jenkins, use your Plesk autodeploy from Git repo. Throw away complex frontend setups, go with $30-$40 glittery ui kit or even an open source thing right from CDN, without less, sass, gulp and all that jazz. Make use of create-react-app if you can’t avoid using React because you’re making a web application.
Throw away AWS, Azure, Docker, Kubernetes and everything like that. Buy a cheap PHP7 hosting with pre-installed MySQL and do everything as simple as possible. If you have to use NoSQL, go with free Heroku with git autodeploy, NodeJS Express and free Mongo addon.
MVP should be ready in two weeks. As soon as your infrastructure is that simple, you don’t need unit tests. They’ll slow you down. Once you MVP is ready, go get funding, throw away first MVP, hire a decent CTO and let him create the spec.
Right there, it may be noticeable that unit tests are probably the biggest and baddest workaround imaginable. It gives you false sense of controlling your bugs, while you don’t have any control at all. Obvious bugs that unit tests can catch are easily noticeable at concise system, while quirky bugs couldn’t be caught by them because you can’t even imagine them while writing your unit tests. At this point, unit tests are just waste of time.
So, the whole picture is clear: at a small scale, you don’t have time to write unit tests and don’t have many bugs because of simple tools and standard patterns. At large scale, you need a spec to prevent bugs, unit tests become redundant as long as your spec is good.
In conclusion, I can tell that I’ve been developing a Clojurescript + CouchDB app for some startup, and in 8 month coding by spec I made myself I encountered only two or three bugs, all related to external JS tools and its quirks.
Have a good time!7 -
When a senior programmer told you they're done implementing the feature but don't know how to write the unit tests
1 -
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. -
In interview tests I don't mind you testing for me to know something. However I don't care for tests that are designed to verify the lead is smarter.1
-
So, after having my mental breakdown with the 500k LoC Zend Frameshit PHFuck 5.5 with 0 test project, for a whole year; and after moving to a better job, I now inherited a React/Node/GraphQL project with a shitty architecture. It's so shit technical debt can almost be payed with actual cash... or flesh, ass-for-arch.
However, line test coverage is over 90%, so I guess it is an improvement.1 -
Async tests are seriously fucking fragile there has to be something I'm missing here this is way too unreliable5
-
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 -
JUnit 5 and Mockito are so cool! Writing tests is so much fun! Having tests is a blessing! 👉 WRITE TESTS 👈
-
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 -
Guys, I need to finally start making unit tests. I started a project a few months ago and I wasn't aware of the importance of making them. But now it is freaking big and I don't know where to start. Any tips or reading materials? The app is written in Node.JS.4
-
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.
-
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 just reviewed a pull request with a test case like (pseudo code):
# Test MyService
const mock = createMock(myService.myMethod)
.whenCalledWith("foo")
.returns("bar");
assert(mock.myMethod("foo") === "bar"));
Why though? Why are we testing the mock? What is happening here? This test has no reason of being there instead of a fuzzy feeling that we now have unit test to lure us into a false sense of security.
I asked why we don't do an integration test. Response was: "They are slow."
Well, duh, but at least they would actually test something.
What do you gain by asserting that the mock is working the way you set it up?3 -
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 -
How my friends work day goes, I worked at the same firm and on the same project, I dont pity him.
70% debugging
25% refactoring - after his pull request was denied a few times, and had to rewrite that code in question a few time. I think most people go mad
3% test writing
2% code writing -
There was MCQ test based on Java we were required to give by our degree college, partnered with this firm.
The image is not even the tip of the iceberg.
3 of the four options in every question were same.
Select A and later come back to the question, you'll find option C as selected.
Never was I ever this frustrated, not even all the times I've encountered a NPE.
Shitty shitty shitty as fuck.
-
My boss put me on cold water working on components documentation for two days but didn’t stop to check if what I did was satisfactory or if he wanted another standard. Today when he finally saw I realized lots of errors that I didn’t see due repetitive task
-
Write meaningful unit tests! Unit tests are like micro documentation for your code that you can validate in seconds.3
-
when i look at the code structure of the project i work on with my friends, i always think about how to implement the SOLID principles of bob martin for clean code
... and then i think about the clusterfuck of almost unmaintainable code that has been created over time and all the unit testing that doesn't exist at all and how much time and effort it would need to correct that code and how i realize that i don't even understand the principles and how to implement them
... and then i give up and go on coding even more mess
... and then i repeat😅😖😩3 -
A team blacklisted a series of words in order to prevent XSS. Obviously they failed terribly. Like they filtered 'alert(' and crap like that. Like a hacker is going to alert stuff using xss. I opened a bug to their team.1
-
I'm going to start uni next moths. I'm very excited!
But a friend of mine that took the same course just told me that all the programming tests are going to be by hand, and I'm used to do it in an IDE.
C++, C#, Java, JavaScript, PHP, etc. All by hand...
Sweet mother of Jesus.........
Any tip?6 -
Oh here's a good one. When the managers realised one of our apps is a giant hunk of crap that wasnt thought through at all and was lazily thrown together, and their solution is "meh let's just rewrite it in Swift on our new platform. And those other guys can maintain the old one and continue to do hotfixes for it until we are done".
I've been telling them for the past year that its the worst codebase I have ever seen and the lack of tests is disgusting and not something we should dare to release to paying customers (especially when those customers work in healthcare!!!). The best part was when one of them promised we would all be working on the new shiny platform by Christmas. That was last year. And I'm currently the poor bugger doing the legacy maintenance and in the process of trying to get moved to a new project. So much for managers promises amirite... -
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
-
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 -
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! -
alias "phpunit-commit"="phpunit && git add . && git commit"
This have saved me so much time.
- phpunit
- if all GREEN, we add and commit to git
(Yes, theres likely tools for this, and some that run after pushing - but I've already avoided some faulty commits)3 -
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.... -
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?5
-
Just took an online C++ test as part of a job application.
Got 7/10
Pass mark was 5.
I haven't used c++ for two years. What do you think my chances are for going forward?
Feeling really nervous about it.3 -
Current task: take a word document of test cases and turn them into code.
My issue with this: the document appears to have been written by a drunk 10 year old with no knowledge of the system or development in general.
Half of the English makes no sense in the document, let alone the technical points.
My favorite mistake that is all over this document, "this will not cause an error but will reboot the system" they're the same thing in our context, raising the error reboots the system.
I want to cry. -
I don't get it I really suck at code tests on interviews. Applied for a new front-end job and been working in the industri for 3 years so I see my self as pretty proficient in JavaScript. But my brain stopped working on the code test =\ Hope they still proceed with the interviews so I can convince them anyway2
-
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'm trying. I'm really trying to understand you Dagger 2. But every time I read articles, look at source code and just try to understand how your magic works, I end up copy pasting the sample code. And then I don't know what I even did ffs.
Maybe it's so damn hard for me because I don't understand Dependency injection? But I think I do... What can I do to understand you? Please tell me?
Especially when my use case requires nested fragments and isn't just that typical inject fragment to activity sample...
And now I have to fill in all of the injected fields in my integration tests by hand because I can't figure out how to fucking make you piece of shit do the motherflipping injection!! Fuck.
I need painkillers... My head starts hurting1 -
Let's talk about one of the two hard things in programming - what's your preferred test naming convention and why? I'll have to create plenty of those now, while the project I'm working on is still small, and I don't know which way to go. It's Spring (Java), but I don't think it matters that much 🤷4
-
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 😢😢😢5 -
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. -
Is it just me or does writing a unit test for something that's meant to fail feel totally arse backwards?
Don't get me wrong the test succeeds in asserting what it's meant to assert, it just feels backwards writing it xD1 -
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 -
Damnnn my Team lead is hinting that i write a test for the feature I paired with a team member.
But the large django code base is ridden with abstract classes and classes and inheritance etc...its going to be a long night -
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.
-
Finish the story and all tests pass
*notification another merge request been approved
Pull changes build, all tests faill
-
Best part about being a dev: Encountering problems and being able to fix what I find.
Having the flexibility to reason through solutions and occasionally write my own. -
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 -
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. -
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 -
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.
-
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
-
So, in a microservice or web service pattern what is most important unitary test or functional test?
-
!rant
When a method and its unit tests are saying different things...
Terrible headache and utter confusion.
Please, update your test case to reflect whatever changes you made to your method. -
That moment when you spend an hour walking through new code because what was working suddenly stopped and the changes made couldn't possibly have botched it...
You realize that a midnight process deletes and recreates the source of this code's data.
This is why I shouldn't take work home. -
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... -
Me: Let's try the ballmer peak
One Beer
Other Beers
One Cuba Libre
Two Cuba Libres
Me: I think I'm ready let me take the test
Result: 93/100
mmm Interesting, let me try more. -
Caching is cool. But damn it! When it comes to testing it's just a hell of a pain to search and disable every caching found to ensure the result is repeatable.
npm cache, /tmp, ~/.cache, and more, and more!
Top Tags
Weekly Rant
View