Two unit tests, no integration tests.

all unit tests passing

This passes all unit 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)

Unit testing be like "all tests passed"

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 fml

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.

When your colleagues have no tests for their code and tell you not to touch it, because it WORKS!

2 unit tests. 0 integration tests.

And for tests: 404

When you write 2 unit tests and no integration tests.

About 11 months I posted that my wife was pregnant. I now have upgraded to son 1.0. All without writing any tests!

I think my automated test texts me more often than my boyfriend does

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...

software developers and testers be like

integration tests...

"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.

Rage debugging...

When your colleague is having the time of his life writing unit tests

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?"

* 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 folder

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 :/

How to quit smoking as a developer, tutorial:
#1: You're only allowed to smoke when every unit test is passing.
#2: ???
#3: Profit

Made me a little debugging duck out of post-it while waiting for my program to finish testing

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.

QA trying to break my code

"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.

This is my life now...

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...

Bae: come over
Me: can't, tests are failing
Bae: Flatmates aren't home
Me:

As shared by a friend,
Beyoncé Driven Development (BDD)

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.

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.

Get assigned ticket.
Finish the most of the feature. Finish most of the specs.
Push.

Second dev wants to own accounting half of the ticket.
Rip out half my changes, rewrite specs.
Push.

Code review asks for minor changes.
Finish them.
Push.

Product creep creeps the scope.
Finish the feature again.
Push.

Product creep creep-creeps the scope.
Finish the feature again.
Push.

New release happens.
Merge in master; fix conflicts. Run specs; random unrelated specs fail, some fail intermittently. Rabbit holes of complicated, unexplored, obviously-flawed code.
Fuck that. Push.

!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.

Some former colleague just blatantly commented out units tests I wrote for his build to pass. What the...

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.

build
D E S T R O Y E D

We love unit tests.

How to pass tests, sooner or later
(free code camp)

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.

I am slightly upset about this shit

Client requests 100% test coverage..

someFunction();
expect(true).toBe(true);

Problem solved

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.

never wrote any unit tests

*** 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 ***

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.

Write so many tests that QA goes out of job 😃😃

ARE YOU FUCKING KIDDING ME JASMINE
FUCK YOU FUCK FUCK FUCKETY FUCK
FML

"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.

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"

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!

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.

"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.)

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!

One of the best feelings when programming

I love TDD.

It's so relaxing to know that your fix didn't fuck up anything else when the tests pass.

"I'm almost done, I just need to write some tests"

Almost all fail

"Okay, maybe I need a few more days"

and this is why continuous integration exists

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
Fml

ninhethy ninhe pefhcent tehsts coverhage, fiiinhe, nhow mhy phodhucht ihs high qhualithy

That moment when your tests succeed on the first run after you've written them

Unit tests fail.

Re-ran it again without looking at details.

Unit tests pass now.

What. Why?!

Now I can't sleep at night.

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... 😂

It do be like that

trust my unit tests

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 meeee

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'...

Not writing unit tests :(

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.

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.

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?

I love it to maintain old unit tests which were not executed for about 5 years. 2/197 are green (╯ ͠° ͟ʖ ͡°)╯┻━┻

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 😰

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.

True stuff here

Not doing unit tests

Has anyone felt the astonishing effect that is writing a whole bunch of test classes, hitting run for the first time and they all pass.

I'm kinda sitting here staring at my screen in disbelief, either these tests all passed, or I've really missed something and they passed anyway, or it's just a lying piece of shit trying to question my own abilities... all are possible right now.

And no, they are not " assert(1,1) "

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.

In my team, unit tests are called so, because every Dev is a 'unit' who manually tests their own code...

how not to name tests

Fuck the tests...

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.

Never back down

We're good here, let's push it to prod.

Do unit tests.

finally someone said it

It’s not Friday yet, which means I have no excuse for delaying fixing this.

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.

After a developer writes a 1000 lines of code with no unit tests then it is time to go home.

I refuse to believe that this beautiful fix isn't working

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!

After a long time I finally reached this milestone of 100% code coverage. I often asked myself why I had to test every function, no matter how small. But this log output of 100% was worth it.

Project has no tests

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.

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?

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.

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* :'(

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? :)

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.

Me on Google right now:
"How to create Android unit tests"

Sometimes, usually during the evening, I lower the lights in the living room, put some of my greatest Scotch in a glass, and stare at this fine and beautiful piece of code I wrote a long time ago that I am really proud of.

Trying to love writing unit tests.

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 ... fml

"Why use tests anyways"

My matryoshka keeping me company, because of course when you are alone testing a last hour deployment. shit will happen

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.

When it finally clicked on how to write tests first and I could actually make code progress with it.

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.

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.

-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**

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?

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.

Always test your fucking mocks
I spent 3 weeks debugging every part of the application, except for the mock network connection. The mock network connection didn't trigger closing events on the sender side.

Let's get real serious for a second here guys... How do you unit test a unit testing framework?

I think I need to start writing unit tests for my unit tests...

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

I abhor timed code tests. Do you really want to test how fast I can write crappy code?

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.

Madness

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!

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...

That feeling when something you write works, and every part is tested. And your happy with it

I love making small changes.

Roll safe. ;)

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.

I run update without where on mysql console on production database Today.

CLASSIC

Just because I needed to fix database after bug fix on the backend of the application.
I thought I wrote good sql statement after executing it on my local machine and then everything got bad.

Luckily it was only one column with some cached statistics data and I checked that it was not important data before I actually started fixing stuff but still ...
Almost got hard attack afterwards.
Made a script to fix this column and it took me only 15 minutes but still...

Bug was caused in part I got no unit tests and application grow after 3 years of development from simple one for one customer and volumes of documents around 50k to over 40 customers and volumes over 2mil per month, don’t know how many pages each, just in one year after we completed all needed features.

I have daily backups and logs of every api operation but still.
I think this got to far for one backend developer.

I got scared that I will loose money cause I am contractor and the only backend developer working on it.
I am so tired of this right now I think I need a break from work.

Responsibility is killing me so hard right now.
It will take a week to get back to normal.

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.

In hindsight, this was entirely predictable

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 ...

!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 :\

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...

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.

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...
AAARRGHHHHH

Real men push to master and test in prod.

we dont need tests :/

nodejs automated testing grunt mocha chai etc etc. Awwww yeaaaa

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)

Start writing unit tests

Functional test are failing.

Expected: 7109
Got: 9000

Grep code-base for 7109. No findings. 0_o

Dig through test setup written by a drunk.

Find:

assert(actualPrice === 1800 * conversionRate)

Goddamnit. You shall not calculate your expected values in a test setup.

Change one line of code. Fix the tests for the next 6 hours. This is absolutely normal... NOT!

How it feels being an independent developer working for a big company

Making them unit tests pass

When you test only positive scenarios ;D

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 well

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.

Assertequals("Fail","Fail") in the catch block.
Things developers do to bloat their test coverage at my organisation,
I am #stuckWithIdiots

Management sees green

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 ...

That feeling when your unit tests start passing...

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 down

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

TFW when you discover your tests have bugs, and your code was broken all along 😡

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++

😆

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 😅😷

I always take pride of writing correctly tested code. So for each piece of code I write, there's another piece of code that check that it's working correctly.

But wait a minute, my test code itself is untested. Should I test my unittests?

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 😂😂😂

Speling eror is not my bug

Feeling good, code compiled but failed tests :(

I just found out I make tests best if I just don't care if I fail or succeed..

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 standards

Fuck Unit Tests.

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 😂

All tests passed. Now I can sleep peacefully.

When my tests pass AND CI succeeds. Or just when my php code works haha

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.

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 data

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 👹

I hate it when I'm bug hunting and the fucking unit tests don't want to fail. Fuck you.

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.

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 :(

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.

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

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.

Almost there...

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!

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. )

When a senior programmer told you they're done implementing the feature but don't know how to write the unit tests

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

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.

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...

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.

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?