Let's clarify:
* Github is not Git
* Android is not Java
* Unit test is not TDD
* Java is not OOP
* Docker is not Devops
* Jenkins is not CI
* Agile is not institutionalised total chaos
* Developer is not Printer Support

Do you follow test driven development?

Dev: "Ah, I finally fixed that code I was working on the other day and got it pushed to staging!"

Almond: "Ah, great! What was the issue in the end?"

Dev: "It was an odd one - it wasn't actually my code that was the issue, there was a bunch of other code getting in the way."

Almond: "How do you mean?"

Dev: "It kept complaining about something called a "unit test" failing - so after a while I found the right unit tests, deleted them, and now it works great!"

Almond: "..."

In unit test
Me: *uses everything I have , writes a program with my own logic, tries to make it better by adding some user friendly features and also documents the whole code*
My Friend:*copies from textbook*

RESULT
ME:9/10
HIM:10/10

"Your code isn't present in the textbook, so I can't say if it'll work but still I've given you marks" -_-
What kinda system is that -_-

Sometimes I'm lazy and if I'm writing unit tests and there's a complicated case to test I'll just skip it.

- "I disabled unit test to make this work..."
- *Force choke*

Two unit test suites. No integration testing.

Not so much screaming as staring in disbelief, mumbling profanity in his direction...

When my department lead said "I don't think this unit testing hype or code reviews make much sense, it's more efficient to just make a checklist and test the application yourself"

This was the QA department of an aerospace company, we wrote NDT software to do image recognition on xrays of alloy welds and micrometer laser measurements on fuel tank surfaces. Software which is quite mission critical, a single misrecognized welding fault could literally cost up to half a billion dollars — not to mention that it's a very sabotage & espionage sensitive industry.

After raising some hell he was replaced though.

Newspaper: This CEO is one of the top entrepreneurs in the country, a true tech visionary shaping the future.

--- 3 months previous ---

Lead dev: O2 have said they are will pre-install the app on all their Androids but they need documentation from us.

CEO: documentation? on what?

Lead dev: Our unit test coverage, bugs found / fixed, security scan results, performance assessment, if and where its storing any data etc.

CEO: Ah were not doing any of that crap, bloody unit tests, its not necessary, tell them no.

lead dev: ..... eh ok

O2: *approved*

... true visionary, well done to everyone involved.

Dedicated to All Programmers Who hate Testers

Only write unit tests. It will be fine.

Dev: Breaks unit tests

Same dev: Merges it to master anyway

Same fucking dev: Can't merge to master coz CI is screaming at you? Merge locally and FORCE push.

Me: Hi, I'm blocked. I can't merge to master coz of this failing test, can we get on a quick call and figure this out?

Same fucking fuckface dev: *after 3 fucking days* Yeah, I don't know why it's failing.. the results seem to be inconsistent..

Jesus Christ. I am so close to leaving this side-project because of the frequent shit I have to go through with this fucking idiot.

God I wish I didn't need the money.

Worst bad practice..

Manager: I need code today
Developer (thinking) : let me give it without unit test. Anyways tester will test it.

Manager to tester: complete testing fast.

Tester(thinking): developer must have unit tested it. Let me skip it.
Enjoy testing completed.

God help clients.. 😊

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

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

Guy at work put Assert.AreEqual(true,true) in a unit test!

Lord give me patience 😂

QA: You need to write a test script for your new web app before it can go live

Me: ok, I'll write some tests in PHP unit and automate the tests.

QA: Oh, can you do that? We just normally write a list in excel then go through each line and write pass or fail at the end.

Me: yeah, good one.

QA: Umm, I'm not joking.

Queue awkward silence...

When you changed a logic structure but the tests still pass.

Worst of many. Had to work with someone who could be accurately described as a monkey in trousers with strategically cut fur.

Him: "I have refactored code now I have to refactor all your goddamn unit tests"
Me: "so?"
<silence>
<checks his commit>
Me: "why have you commented out every single line in all the unit tests?"
Him: "I DON'T BELIEVE WE SHOULD HAVE ANY UNIT TEST. THEY ADD TIME".
Me:"You cannot be serious. Apart from the obvious mistake in judgement why in the name of blue buggery fuck did you not delete the files? Have you not heard of source history?"
Him:"...."

I became his lead.
He left.

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.

I found an interesting job post on SO, I decide to apply. It comes with a programming test. A simple unit test that must pass (see current-1 post). I get it passing, go to send off my resume and code and the fucking email they supplied isn't valid or active. Fuck you. Eat dicks. Useless fucking HR.

True Story . . . .

!rant

Got myself a christmas present.

JacksOnF1re child = Girlfriend.createByInject(JacksOnF1re);

And yes, we did the unit test.

Wow

PM asked us to skip the unit test and just deliver untested application to SIT environment due too tight timeline. But when there are defects raised by tested, PM asked why got bugs and asked us to fix them immediately while we have to develop other new features at the same time.

I have never written a single unit test in my life. Hence my code breaks from time to time. Karma is a bitch 🤣

I saw one guy in Office writing unit test cases and documentation for his code .
Such a psychopath!!!

Me seeing my code can't find ./script.js but debug says it can find it

Going through code left by a senior developer who quit.. Dated 2015..

public static T IfThenElse<T>(bool isTrue, T ifYes, T ifNo)
{
if(isTrue) { return ifNo ; }
else if(!isTrue) { return ifNo ;}
Debugger.Break();
throw new Exception("") ;
}
.....
There was a unit test for it well
....
............. Wow, just wow

They said, try new unit tests...

Programmer one-line horror stories? A few off the top of my head:

Segmentation fault (core dumped)

'Undefined' is not a function

Unit test failed: expected '0' but got '-1'

Connection to 'localhost:8080' has been lost

Malformed JSON string at col: 46,372. Expected '}'

//TODO: write unit test for this

Not proud of it..

Yes! you made a difference.[image]
P.S.
started working at a startup as an intern(android app developer), Most of my work is like debugging the code, new feature implementations.
And the codebase is full of this kind of shit(even worse) plus literally zero documentation(not even for API's), not even a single line of comment in complete project(40K-50K), not any unit test/ UI test.
The funniest thing is when I ask for documentation he(boss | *) said: I am documentation.

This really needs a unit test.

The only book that will never be written

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.

I am like the weakest programmer at my job. I wanna improve and get better. Understanding how to write good unit test to reading code. Damn it. I just wanna be better.

A principle software engineer told me the only reason to unit test was to reduce QA headcount.
He’s a hero. Heroes get promoted here.

My teachers use the number of commit you do as measure for the quality of your work.

I've the least number of commits this week since I spent most of the week doing encriptions algorthims instead of UIs and unit test as the rest of my team.

But, by their logic, I'm the worst of the group. It's simply stupid.

Dynamically typed languages are barbaric to me.

It's pretty much universally understood that programmers program with types in mind (if you have a method that takes a name, it's a string. You don't want a name that's an integer).

Even it you don't like the verbosity of type annotations, that's fine. It adds maybe seconds of time to type, which is neglible in my opinion, but it's a discussion to be had.

If that's the case, use Crystal. It's statically typed, and no type annotations are required (it looks nearly identical to Ruby).

So many errors are fixed by static typing and compilers. I know a person who migrated most of the Python std library to Haskell and found typing errors in it. *In their standard library*. If the developers of Python can't be trusted to avoid simple typing errors with all their unit tests, how can anyone?

Plus, even if unit testing universally guarded against typing errors, why would you prefer that? It takes far less time to add a type annotation (and even less time to write nothing in Crystal), and you get the benefit of knowing types at compile time.

I've had some super weird type experiences in Ruby. You can mock out the return of the type check to be what you want. I've been unit testing in Ruby before, tried mocking a method on a type, didn't work as I expected. Checked the type, it lines up.

Turns out, nested away in some obscure place was a factory that was generating types and masking them as different types because we figured "since it responds to all the same methods, it's practically the same type right?", but not in the unit test. Took 45 minutes on my time when it could've taken ~0 seconds in a statically typed language.

Last meeting I suggested we started using unit test and perhaps TDD on our platforms.

My boss is open to it and everyone seems to like the idea...

Now I just discovered that our dumbass coworker is trying to say by my back that its a bad idea to double the code efforts and that he sees no point in it...

Well dumbass cock sucker who can't even fucking remember how to write `docker-compose up` without messing things up you can fuck your self because you are certainly gonna be fucked sideways untill the end of the year.

I think im sick. Not because my whole body hurts, my nose is running and i cant even move, but because i just had the idea that i should unit test my personal project.

Write only one unit test, so I don't feel bad for not writing unit tests.

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

Unit test - done
Integration test - meh..

Skipping unit tests and documentation ...

I'm starting to recover after not writing a single test for the first 6 years of my professional carrer (wasn't taught in school, didn't know where to start, man I should have really found a mentor earlier), and barely any documentation (I was the sole developer for several years, and just didn't get into the habbit).

Unit testing is still not a habit, but now I have the first tests to serve as an example and an idea what/how to test at least, and I try to get every new "framework" function/class at least commented properly.

Wish me luck

!rant
Wrote my first unit test. Strangely feels satisfying.

When you are running some unit test cases with less code coverage

Me: We really need to improve our unit test coverage.
Team/Boss: <sarcasm> Haha yeah.
Production Bug: I'm doing something nasty to a client, because a dev broke something but no test coverage.
Boss: How could we have prevented this?!

Working in the embedded systems industry for most of my life, I can tell you methodical testing by the software engineers is significantly lacking. Compared to the higher level language development with unit tests and etc, something i think the higher level abstracted industry actually hit out the of park successfully.

The culture around unit testing and testing in general is far superior in java and the rest.

Down here in embedded all too often I hear “well it worked on my setup... it worked at my desk”.. or Oh I forgot to test that part.. or I didn’t think that perticular value could get passed in... etc I’ve heard it all. Then I’ve also heard, you can’t do TTD or unit tests like high level on embedded... HORSESHIT!

You most definitely can! This book is a great book to prove a point or use as confirmation you are doing things correctly. My history with this book was I gonna as doing my own technique of unit testing based on my experience in the high level. Was it perfect no but I caught much more than if I hadn’t done the testing. THEN I found this book, and was like ohh cool I’m glad I’m on the right thought process because essentially what they were doing in the book is what I was doing just slightly less structured and missing a few things.

I’ve seen coworkers immediately think it’s impossible to utilize host testing .. wrong.

Come to find out most the of problems actually are related to lack of abstraction or for thought out into software system design by many lone wolf embedded developers.. either being alone, or not having to think about repercussions of writing direct register writes in application or creating 1500 line “main functions” because their perception is “main = application”. (Not everyone is like this) but it seems to be related to the EEs writing code ( they don’t know wha the CS knows) and CS writing over abstraction and won’t fit on Embedded... then you have CEs that either get both sides or don’t.. the ones to understand the low level need but also get high level concepts and pariadigms and adapt them to low level requirements BOOM those are the special folks.

ANYway..the book is great because it’s a great beginner book for those embedded folks who don’t understand what TDD is or Unit testing and think they can’t do it because they are embedded. So all they do is AdHoc testing on the fly no recording results no concluding data very quick spot check and done....

If your embedded software engineers say they can’t unit test or do TDD or anything other than AdHoc Testing...Throw the book at them and say you want the unit test results report by next week Friday and walk away.

Lol

I finally stopped being lazy and wrote 31 unit tests for my Discord bot.

Nothing is more satisfying than seeing them all pass and the GitHub workflow working without any problems. :)

> Some unit test is not behaving well in my local environment
> Weird, I should print the response from the server, maybe the client isn't receiving what I think it's receiving
> see this

SAY SIKE RIGHT NOW

trust my unit tests

I've been writing a complex mutation engine that dynamically modifies compiled C++ code. Now there's alot of assembly involved, but I got it to work. I finished off writing the last unit test before it was time to port it all to windows. I switched into a release build, ready to bask in the glory of it all. FUCKING GCC OPTIMIZATIONS BROKE EVERYTHING. I had been doing all my dev in debug mode and now some obscure optimization GCC does in release mode is causing a segfault...somewhere. Just when I thought I was done 😅

I fucking hate the fact that this group I'm side-hustling for gives maintainer access to every shitty dev they have.

Dev pushes four commits directly to master branch. Each time, pipeline fails on unit tests.

Shithead ignores failed tests and manually deploys to stage anyway.

Fuckface then declares (in group chat) that her "fix" works on stage and proceeds to merge to RC branch without updating the fucking unit test.

Pipeline fails (of course) and remains unfixed for the last EIGHT FUCKING HOURS.

This is what I woke up to at 6-fucking-AM in the god-damn morning.

*insert multiple expletives and insinuation of mother's excessive girth by comparing waistline to equator

I answered an robocall and all the robot said was "good bye". This must be the unit test of robocalls.

My first new year resolution for this 2017 is learn to do the f****ng unit test before implement the code

Wanna have 120% code of code coverage? Start writing test for unit tests.

Am I the only one who doesn't judge a programmers contributions by commits or change history?

Frequently I'm always near the bottom of contributors, because I don't make a million commits when it's broken. And I don't commit lines that will likely disappear in later commits. I like to finish a function, test it, check it, rework, and then make a "made function()" commit, as apposed to:

"Wrote function()"
"Wrote unit tests for function()"
"Fixed error"
"Code cleanup"
"Style guide compliance"
"Reworked function()"
etc.

Sorry that I keep my commit history clean and ensure it builds.

Everything green and ready for deployment

Today I had to write a unit test to test a method that internally used a random number generator...

Aha
Ahaha
Ahahaha
My test was literally just assertNotNull...

My whole team like to develop the backend of a very complicated platform in python because it is fast to develop. And host the front-end under nginx. And run everything on windows. And without unit test.

When people use Thread.sleep in unit tests to delay execution of threads

How to NOT write unit tests:

A colleague of mine has developed a new package of software, many of our new projects are going to use. So in his presentation of the new functionalities he also showed us that he used unit tests to cover some of his code. So i asked him to show me that all tests passes.

He: I can show you, but one test suit will fail currently.

Me: Why?? You told us, everything is finished and works fine.

He: That's right, but they will fail because I'm currently not in the customer VPN.

Me: Excuse me, WHAT??

He: Yes, I'm not in the VPN that connects me to this one customers facility in Hungary, where the counterpart of the software is runnung live.

Me: YOU WROTE UNIT TESTS THAT TEST AGAINST A RUNNING LIVE FACILITY??

He: Yes, so I can check, that the telegramms I send are right. If I get back the right acknowledgement, the telegramm structure is right and my code is working.

Me: You know, that is not the porpose of unit tests? You know, that these test should run in any environment?

He: But they are proving, that my code is working. Everytime I change something I connect to the customer and let the tests run.

Me: ...

Despite the help of some other developers we could not convince him that this was not good and he should remove them. So now this package is used in 2 new projects and this test suit is still failing, everytime you execute all unit tests.

Tired of reading spaghetti code written by your team mates?

Sit right next to them and ask them to write unit tests for that code.

Smash their head on the keyboard everytime they have to think longer than 10 seconds on how to test a specific logic.

Strangle them with any wire you find nearby till they agree to break up that spaghetti code unless they already started within that 10 second time frame.

When the exercise ends, tell them this is what refactoring is and ask them to pass on the knowledge.

I guess I'm taking the piss.
I just spend half an hour wondering why a unit test failed; turns out all calculations were done correctly, just that -5 + 3 was being calculated and the test expected the solution to be -1.
Well, -5 + 3 does not equal -1 and I'm too stupid to add.

Half an hour. (-_- )

I love Test-Driven Development!

And because of that fact, my heart shatters into thousands of pieces, when I recognize error events on our production nodes which are pointing onto a golden hammer function in a legacy project.

This particular function has about 300 lines with a bunch of subfunction calls and instantiations of helper-classes returning information for workflow.

Refactoring this code to apply proper unit-tests requires a way bigger investment than simply deal with 30 eventlogs a day, because this kind of payment is barely used by customers of our webshop.

This fact is a little itch each day of my work.

Guess it will make me go insane one day
¯\_(ツ)_/¯

xD

I don't get it why there are so many people out, that think testing stupid model classes with getters and setter is needed.

Dude. There is no logic in this class ... it's pure data that gets not modified there (well except if you call the setter)

I've wasted way too much time writting useless unit test because some ppl want to masturbate on 100% code coverage 🤦🏻‍♂️

LARAVEL MEME OF THE DAY
If 60> requests are sent in a short amount of time (and you have Laravel Passport installed) you will not receive an IlluminateResponse instance anymore; you will instead receive a slightly different SymfonyResponse.

Why? For the glory of Satan, of course.

If your code doesn't account for that undocumented garbage, your code will start throwing middle fingers here and there.

Tell me again the productivity joke with Laravel, I've just lost an hour and a half 'cause unit tests were failing and I had no idea why.

how not to name tests

Maybe in special dedication to @kiki.

I cut the unit tests down in LOC size by roughly 50 - 60 % in most projects.

It's really easy once one sees unit tests not as a dunking pile of copy pasta wild west, but rather as a code base that needs architecture and design.

Some extensions, some annotations, some good old helper classes.

Pooooof.

Why I did this? ...

Because it's fucking annoying when you read a PR with tests and need a fucking diff tool to spot the difference between two tests cause they're 80 % the same.

Yeah. Thx for giving me brain cramps, motherducker.

I'm not an expert in unit tests, but if all test codebases look like the "usual stuff" in our projects...

It's no wonder bugs exist...

Nobody Unit Tests.

So it's already 1:15am late night and I am all tucked up in bed watching Roy Oshrove talk on unit testing and ways to write correct unit test. My friend walk in and finds me in bed watching this. He seems surprised as what are you doing ??
I replied it is an interesting talk on unit testing.

He says are you mad? Who the hell does unit testing ?
People out there are spitting on unit test code base. And they don't write unit tests.

Nobody unit tests.!!

I stay calm. I know there is no point of arguing. I said I'll sleep in some time.

And he works as developer, a job that I applied an never got because of connections.

I am optimistic someday I'll find a job that I deserve. The developer world is in danger. !!!

This is why we unit test..

I just want to share this:

When I start working at my last job, I have little idea of what a unit test was.

My boss on one meeting said that unit testing will be mandatory (wich is ok and umderstandable).

Almost a *year* after that, no one still care about them. I see myself doing them the best I can, but I saw things like wrap the assertion line with "try / catch" to lie to the coverage and unit test percentage. Or in other cases directly uploading *manually* the code on the server without test at all.

And then, as the only developer who do the unit test ok I have to do the missing ones and repair the fake ones.

Then when something explodes the question all the managers love to ask "Did we had the testing?"

At least I quit... that job was some crazy shit, this is just one story of many.

Like that other time that my co-workers did not understand why I needed to do POJOs on an android app because the big bad JSON that the app used was working fine....

Watching a well written Selenium unit test doing its thing is one of my most satisfying jobs.

Writing a Unit test to test the Unit test that's testing your application, because you can never be sure about anything.

When the devs "fix" the unit tests by modifying the test cases so they pass.... Bugs are still there, but our deployment succeeds now. Oh federation....

Intern: what’s my purpose ?
Senior dev: you write unit test for my code
Intern: 😓

Sometimes they pay off...

A designer pointed out that at a certain screen size (small tablet or large mobile), a menu was overflowing but had not yet collapsed into a toggle.

The manager comes to me and asks "why don't we have a unit test for that?"

Ugh all but one unit test is passing :-(. I know the code is working- so the problem must be in the test... [add @ignore to test]. Yay they all pass now!

When you made business logic changes but the unit tests still passed

When you feel like your falling behind because at work you don't unit test, use dependency injection or pretty much anything the devs in the community discuss.

Employer: Hey, we are moving an API update live tomorrow morning that could affect our apps. Can you regression test the apps to make sure they all work?

Me: The API team is pushing code overtop of live endpoints that can break them?

Employer: Yes, we need the updates to work with a new product we are developing.

Me: And nobody thought about versioning these endpoints so we guarantee uptime on all existing services using them now?

Employer: We looked at that but it cost extra and required us to use the cloud solution so we don’t use versioning.

Me: Okkk… I also take it that the API’s don’t have integration tests written?

Employer: What are integration tests? Are unit tests the same thing?

Me: No, so when do I need to regression test all 7 production apps?

Employer: The API’s are moving to production at 4am and we need it signed off by 7am.

Me: I only have 3 hours to regression test 7 production apps at 4am? Each app, if I just skim over them, would take me 2 hours each. I will do my best but that’s a very short time to ensure complete functionality.

Employer: Don’t you have unit tests?

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.

unit testing

I asked an intern to write JUnits to increase test coverage and he mocked the method itself which was being Unit tested.

Unit testing is cool and all, but FFS...

If you want unit test - cool. But its not drop-in replacement for functional testing!

I believe each release should be manually tested.

Our best dev/arch just quit.
C dev lead & a dev staying late chatting.

Lead: am building, takes long
Dev: unit testing, time taking

Ask them y they r building on their latitudes when we got them linux precision with xeons/64gb workstation 1 each ?
Both: I code on latitude.

Build/test times. (pure Java/maven)
Latitudes=an hr or more
Precision=2m to 11m
Jenkins Infra we have =10 mins with test & push. Parallel builds support.

Am suposed to help with an open mind. They now want Mac pro

I made some substantial changes to the codebase.
I run all the unit tests, as usual.
A test that has nothing to do with the feature I'm working on breaks.
"Huh that's odd, let me debug that"
I set a breakpoint with the condition set so that it pauses before the test assertion goes red.

I start the debugger and.... all tests pass

Turns out it only happens like 500/10000 times....

This will be fun

Unit tests that do not test anything, even no assertions at all in some of them.

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.

Supervisor: YOU NEED TO INCREASE THE COVERAGE OF YOUR UNIT TESTS! THE FILE logger.js DOESN'T HAVE >80% COVERAGE! IMAGINE PICKING THIS UP 6 MONTHS FROM NOW!

Bro. It's a Winston instance.
I am literally exporting a fucking Winston instance with 0 custom logic.
If 6 months from now I take a file and can't understand a Winston instance anymore, you're well within your right to fire me on the spot.

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

Unpopular opinion: unit tests are often overrated.

Although a well written test suite is almost essential in some parts of the application (I.E. business logic) I cringe when I see hundreds or thousands of line which “mocks” everything to test a micro service which just does CRUD operations on a database, in cases like that unit tests are just a waste of time because almost every operation involves a mock which may not behave like the real database and often needs to be rewritten when the code undergoes a huge refactoring. In these case a integration test suite is faster to write and way more helpful.

Don't test complex functionality before production.. neither unit, nor system tests involved for my android app. Releaseing solely based on hope!

During a period when devs had been told "The board has been promised that we are improving quality, so you must not do anything but write unit tests", I wrote a unit test that compares the number of system colors in .NET to a constant. It's still running today (a couple of years later).

Listened for about a half-hour yesterday to DevA ‘beat down’ DevB writing a console app for trying out a proof-of-concept idea he had.

DevB: “What’s the URL of the development server?”
DevA: “Why? What are you doing?”
DevB: “I’m needing to throw some messages to it so I can capture data for something I’m working on.”
DevA: “How are you calling the service?”
DevB: “I wrote a console app”
- you could almost hear the eye roll -
DevA: “A console app? Why in the world would you write a console app?”
DevB: “Oh..um..no reason. I just need log some test data for something I’m playing around with. How should I do it?”
DevA: “If it’s test data, you should have wrote a unit test. You see, unit tests …”
- yammer on and on for about 5 minutes about the virtues of unit tests…never really explaining anything -
DevB: “Yea, I’m not needing to test the result or anything. I just need to log some data.”
DevA: “Then you should use a unit test for that, not a console app. With a unit test, you’ll be able to validate the data. That’s what unit tests are for. Microsoft should have never put in console apps in Visual Studio. It just leads to bad coding practices.”
DevB: “Um…I don’t care. It’s a console app because I just need data…thanks anyway”

Today, DevC was talking to DevA

DevC: “Charlie is testing the order module, but there isn’t any test data. Do you still have the data generating script?”
DevA: “Oh yea, I’ll send him my console app that populates the database.”

It was all I could do from screaming “You stupid –bleep-er!! What the f–bleep-ck was all that yesterday?!”, but none of my business. Better to devrant about it than start a fight.

We have started working on a new web based editor software. It already has 132 unit test after 3 months but can‘t do shit. In has no functionality, yet.^^

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

There are devs who are chill. Then there's me. Deadlines give me anxiety. Being responsible for the code I didn't write and being blamed for the bugs I inherited stress me out.

The way I was told to write unit tests was particularly terrible.

No mocking of objects or dependencies so the tests ran the actual code in full including updating databases and files. Then at the end of each test there was code to restore all changes back to before the test.

Each test ended up being over 100 lines. Madness.

My boss: Write unit tests for this angular app
Also my boss: what do you mean it will take months to write the necessary mocks for our 177 specs
Also also my boss: why would you need to mock anything for a unit test
Also also also my boss: Just let each component import all the other real components, nevermind that that's an integration test and not a unit test

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

Before i found out about unit tests i'd create a console application where i'd test the functions

Good times

probably every time I see my tests failing.

Each time I am writing tests I'm convincing myself "it's an investment", "spend 2 hours now to save 2 days later", "unit-tests are good".

And each time I'm chasing away ideas like "perhaps they are right, perhaps writing unit tests is a waste of time..", "this code is simple, it should ever break - why test it??", "In the 2 hours I'll spend writing those UT I could build another feature"

Yes, it is terribly annoying to write tests, especially after writing the production code (code-first approach). Why test code that you know works, right?

But after a few weeks, months or years, when the time comes to change your feature: enhance it, refactor it, build an integration with/from it, etc, I feel like a child who found a forgotten favourite candy in his pocket when I see my tests failing.

It means I did a very good job writing them
It means it was not a waste of time
it means these tests will now save me hours or days of trial-and-error change→compile→deploy→test cycles.

So yeah, whenever I see my tests fail, I feel warm and fussy inside :)

If you're a "software engineer" with 10+ years of experience, but you've never written a unit test.... you're just a script kiddie with no right to call yourself a "software engineer".

Guys...

It has come this far...

I... I like test driven development and the amount of unit tests and security it gives you. And I kinda laugh at people that don't take unit testing seriously :p

FUCK YOU WORDPRESS wtffff with that shit , i can't use multisite if running in 8081 port ?, fuck you! your """ cli """, your media folder with that month and year stupid subfolders, your plugins and your fucking unit test running on a complete WP instance. GO FUCK YOURSELF! stop with that shit and remake all that shit.

I am learning about CI/CD and DevOps, and i finally made my first build/deploy/unit test script.

I use arch btw

Fuck me why do my unit tests pass with garbage input.

I can't go into a long weekend with this shit in my head rent free.

> colleague: My file has 79.25% of unit testing coverage
> supervisor: you're almost there! One final effort and you'll get that 0.75%!

Seeing someone this fucking dense is physically frustrating even when I'm not involved

During one of our 'pop-up' meetings last week.

Ralph: "The test code the developers are checking in is a mess. They don't know what they are doing."

ex.
var foo = SomeLibrary.GetFoo();
Assert.IsNotNull(foo);

Fred: "Ha ha..someone should talk to HR about our hiring practices. These people are literally driving the company backwards."
Me: "I think unit testing is complete waste of time."
- You could almost see the truck hit the wall and splatter watermelon everwhere..took Ralph and Fred a couple of seconds to respond
Fred: "Uh..unit testing is industry best practice. There is scientific evidence that prove testing reduces bugs and increases code quality"
Ralph: "Over 90% of our deployments are rolled back because of bugs. Unit testing will eliminate that."
Me: "Sorry, I disagree."
- Stepping on kittens wouldn't have gotten a worse look from Fred and Ralph
Fred: 'Pretty sure if you ask any professional developer, they'll tell you unit testing and code coverage reduces bugs.'
Me: "I'm not asking anyone else, I'm asking you. Find one failed deployment, just one, over the past 6 months that unit testing or code coverage would have prevented."
- good 3 seconds of awkward silence.
Ralph: "Well, those rollbacks are all mostly due to server mis-configurations. That's not a fair comparison."
Me: "I'm using your words. Unit tests reduces bugs and lack of good tests is the direct reason why we have so many failed deployments"
Boss: "Yea, Ralph...you and Fred kinda said that."
Fred: "No...we need to write good tests. Not this mess."
Me: "Like I said, show me one test you've written that would have prevented a rollback. Just one."
Ralph: "So, what? We do nothing?"
Me: "No, we have to stop worshiping this made up 80% code coverage idol. If not, developers are going to keep writing useless test code just to meet some percent. If we wrote device drivers or frameworks for other developers maybe, but we write CRUD apps. We execute a stored procedure or call a service. This 80% rule doesn't fit for code we write."
Fred: "If the developers took their head out of their ass.."
Me: "Hey!..uh..no, they are doing exactly what they are being told. Meet the 80% requirement, even if doesn't make sense."
Ralph: "Nobody told them to write *that* code."
Boss: "My gosh, what have you and Fred been complaining about for the past hour?"
- Ralph looks at his monitor and brilliantly changes the subject
Ralph: "Oh my f-king god...Trump said something stupid again ..."

At that point I put my headphones on went back to what I was doing. I'm pretty sure Fred and Ralph spent the rest of the day messaging back-n-forth, making fun of me or some random code I wrote 3 years ago (lots of typing and giggling). How can highly educated grown men (one has a masters in CS) get so petty and insecure?

Spent fucking 11 hrs on fixing a stupid bug in Laravel that caused all my unit tests to fail. Just because that unit testing method has no unit test...

I've got staff, I've got staff
And they bill time and a half;
Now I only write the gist you see
And they can code the rest

Open source, Fraying nerves
Smoothing out regression curves;
Try this framework, it's ambitious
It was made of spit and wishes.

Coffee rings, at first glance
But of course miss, he's freelance;
And this code base is a truly scary mess
I can't expand the menu
Even chance its home brew, unit test;
Unit test, unit test!

All unit tests pass in eclipse, swap to maven 1 test suddenly fails.

Fuck you maven

Developer just emailed our team a complaint that our logging assembly was resulting in their poor test coverage and they sent a change request to give them the ability to mock the underlying log provider (ex. from the event log to ‘something else’).

Looked at their tests, and they are testing whether or not the .Log was executed (on an exception, if the .Log method was not executed, the test failed), which seemed a bit worthless because we’ve already got coverage in our unit tests.
We had a meeting to discuss the issue.
Me: “I’m OK with changing the logging code if it’s necessary, but I want to understand why.”
DevA: “Logging errors is crucial to the database transaction. If someone removes the logging, the tests should fail.”
Me: “If someone removes the error logging on purpose, then they likely have an agenda and will remove the test validation too. It wouldn’t be an accident.”
DevA: “That’s not my problem. They will have to deal with HR.”
Me: “We purposely prevented someone from intercepting the logging just for that purpose. Your test code already covers the business rule, testing the logging seems out of place. That would like writing a test to make sure the System.IO.File.ReadAllText actually reads all the text from a file. You kinda assume a few smart Microsoft engineers already wrote tests for that.”
DevA: “Yea, I guess that would be silly.”

Got cc’ed an email a little bit ago from DevA to his boss..
“We’re not going to be able to change logging assembly. This may have some impact on our overall test coverage as those lines of code will not get testing coverage. You will have to let the DevMgr know we will not meet our test coverage goals.”

WTF!

Fixing unit-tests that expects 2017... kills my motivation at first workday this year.... I hate my coworker -..-

So I wrote a service a couple of years ago to generate PDFs from some documents. Fully working, covered it with tests (unit and integration). Code was clear and easy to follow.

I've been promoted and the engineer that took it over just went in and rewrote half of it. That would be fine, but they also just deleted every test. So now it's untested.

Glad that's not my problem anymore, I geniunely hope it breaks

*Filling out unit test plan for tester which is an Excel Document*
*Excel keeps trying to correct capitalization on a word that I want capitalized over and over*

LISTEN YOU PIECE OF SHIT! If I didn't want to capitalize that word I wouldn't have capitalized it! Just do what I tell you to do! YOU ARE A PIECE OF SOFTWARE! YOU DON'T TELL ME WHAT TO DO!

If I had a nickel every time the unit tests failed not because something was wrong in the code, but because someone had messed up the unit test I'd be able to retire early.

I just spent the better part of 10 hours hunting down a bug in some production code only for the test to be wrong because the person who wrote it had mocked the http response incorrectly.

Nothing I did to "fix" the code worked, because nothing was wrong with it...

rant?
When you want to write the unit test that demonstrates a subtle bug, but before recreating the same preconditions you end up writing 15 other tests, testing a lot of other stuff too, that in turn show other bugs, and skyrocketing the coverage (that was sitting at 0% actually).
Like I wanted to repair a hole in my umbrella to not get wet, and built a house instead.

Fucking fuck sonarcloud and everything about it. Part of the build pipeline for us to deploy code is to ensure that 90% of the code is covered by a unit test. Great in theory, horrible in practice. You think you've written enough tests that actually add value and test a valid piece of functionality but NO, sonarcloud throws a fucking fit because you're at 89.888 then your branch is going nowhere. Because everyone else gets to this stage and writes just enough tests to get the coverage to 90.01% then it becomes a stand off of who will break first; the code coverage threshold or your mental state.

Unit test!!!
Grrrrrrrrrrrr

When I'm stuck at something and can't think of a way to solve it, I just keep running the unit tests and stare at the screen. And then youtube. And then I feel terrible.

Are there people here who actually unit/integration/end-to-end/stress test (almost) everything? Or is it a common fact that nobody has time/budget and/or needs to do so?

I like to think I test all the code I write, but to be honest, I think it's closer to 1 to 5%

A dev colleague told me today « the frontend is a huge unit test of the backend ». Ideas?

Ah perfect... Now none of the unit tests pass...

Ngl, I'd probably become one of those guys that tries to port DOOM onto things, or maybe maintain some old repos. Maybe fuck around and actually write a unit test idk

*class ends, close laptop*

Ten hours later (right now)

Me: 😶 can't remember why these unit tests failed... Let's run again and see why.

*build success, runs more test cases and tests, all builds fine*

Best feel ever 😎

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 😂

Trying to refactor legacy code can be a real adventure. It's like exploring an ancient ruin, except instead of hidden treasures, you're uncovering cryptic code and dead ends. But the real plot twist comes when you realize there are no unit tests to guide you. It's like trying to navigate a maze blindfolded - you never know when you're going to hit a dead end and end up with a headache! 🤯

this really happened:
Interface Team Lead: "hey I want any time deployments and better QA"

Me: "ok sure. I have CI/CD, but yiu need to work in feature branches / tags, and make sure your code passes automated builds and unit tests"

Team Lead: "I dont have time to test it makes me unproductive! and creating a branch is an extra step which is going to set me back. Im telling the boss you are impacting performance!"

Me: "you want better deployments and QA, but you can even create a branch or tes your work?"

Team Lead: "We have deadlines!"

Whenever anyone asks me why I dislike C++ I'm just going to point to this current app I'm working. Had a unit test with an extern method declaration that had 7 or 8 different parameters. No big. Problem is that the ACTUAL definition of the method had 1 less parameter than the extern declaration. It worked perfectly fine in x86. Ported to x64, compiled fine, hard crash at runtime. Debugger not a super lot of help. Took me a couple days to figure that one out. Also I am broke so I can't even drink the pain away. Neat.

I've been writing unit tests for an existing project for a couple of months now. I'm not experienced at automated tests, so I'm not sure what's good unit tests supposed to be, but the unit tests that I wrote basically just confirm the flow that already implemented, which to my limited understanding of unit tests is supposed to be the other way around. The good thing is that I could catch some minor problems with the implementation such as not imported class used, the wrong variable used since the project is a rewrite of legacy code so a lot of copy-pasta, I also have to wrap some part of the code that interacts with the filesystem in a DI class so I could test that part.

"I don't think we should be playing with our privates {variables} like that" - framework designer

= context =
It was noticed that we have too many setter functions to change private variables just to do unit tests. So we had a small meeting to discuss what to do about this.
Options:
- don't do the test
- ignore till another time (ie: keep the functions till its a problem)
- put the variables into a provider
- use reflection (the above quote was a reaction to this option)

That feeling when your newly added calculation module now has 93% code coverage in unit tests, with the client working on a test case for the last bit.

I was wondering why my tutor needs a whole ass week to accept my MR.

Today he rejected one, so I got a chance to look at whatever he's doing.

He's checking line by line every single test I make and creates a variable for each dumb thing.

𝘦𝘹𝘱𝘦𝘤𝘵(𝘴𝘰𝘮𝘦𝘵𝘩𝘪𝘯𝘨.𝘪𝘥).𝘵𝘰𝘚𝘵𝘳𝘪𝘤𝘵𝘌𝘲𝘶𝘢𝘭(𝘴𝘰𝘮𝘦𝘖𝘵𝘩𝘦𝘳𝘛𝘩𝘪𝘯𝘨.𝘪𝘥)? No, this is bullshit.

𝘤𝘰𝘯𝘴𝘵 𝘴𝘰𝘮𝘦𝘵𝘩𝘪𝘯𝘨𝘐𝘋 = 𝘴𝘰𝘮𝘦𝘵𝘩𝘪𝘯𝘨.𝘪𝘥
𝘤𝘰𝘯𝘴𝘵 𝘴𝘰𝘮𝘦𝘖𝘵𝘩𝘦𝘳𝘛𝘩𝘪𝘯𝘨.𝘪𝘥 = 𝘴𝘰𝘮𝘦𝘖𝘵𝘩𝘦𝘳𝘛𝘩𝘪𝘯𝘨.𝘪𝘥
𝘦𝘹𝘱𝘦𝘤𝘵(𝘴𝘰𝘮𝘦𝘵𝘩𝘪𝘯𝘨𝘐𝘋).𝘵𝘰𝘚𝘵𝘳𝘪𝘤𝘵𝘌𝘲𝘶𝘢𝘭(𝘴𝘰𝘮𝘦𝘖𝘵𝘩𝘦𝘳𝘛𝘩𝘪𝘯𝘨𝘐𝘋)

I don't even know why you would take a week to accept a merge request when all you're doing is creating variables for things you use only once. I'm not even mad, I'm not ranting, I just need to know why would you do such a thing

I am the unit test guy now, please send all of your untested and poorly thought out code my way to be tested

Today, I fixed a dodgy unit test by stopping time.

(I overrode the time() method to always give the same result)

I guess everyone in their company knows how to write unit tests except us.

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

Every. Single. Time. I've tried to learn and implement proper Unit/Instrumentation testing, the main Android devs decide to go for something else or introduce some feature or Gradle plugin that breaks every tutorial out there. I find it way easier to just test everything manually than learning the new yearly trend. Am I the only one?

Killing people is bad. But, there should be a law to allow killing people who don't write proper unit tests for their code. And also those "team leaders" who approve and merge code without unit tests.

Little backstory. Starts with a question.

What is the most critical part of a quoting tool (tool for resellers to set discounts and margins and create quotations)? The calculations, right?
If one formula is incorrect in one use case, people lose real money. This is the component which the user should be able to trust 100%. Right?

Okay. So this team was supposed to create a calculation engine to support all these calculations. The development was done, and the system was given to the QA team. For the last two months, the QA team finds bugs and assigns those to the development team and the development team fix those and assigns it back to the QA team. But then the QA team realizes that something else has been broken, a different calculation.

Upon investigation, today, I found out that the developers did not write a single unit test for the entire engine. There are at least 2000 different test cases involving the formulas and the QA team was doing all of that manually.

Now, Our continuous integration tool mandates coverage of 75%. What the developer did was to write a dummy test case, so that the entire code was covered.

I really really really really really think that developers should write unit tests, and proper unit tests, for each of the code lines (or, “logical blocks of code”) they write.

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!

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.

Me: Where is your unit tests?
Dev: I tested manually and it worked.
Me: What if there are changes to the code in future?
Dev: We'll manually retest the implementation. It'll be fine.

*flip table*

I'm a strong believer in the triple-A unit-test pattern: Arrange, Act and Assert

Anyone else that uses this for their tests? Do you see any cons to using this approach to writing tests? Are you using an alternative?

It's more of a QA rant....
A Website takes address information via POST. Since Selenium can not do POST properly devs said: "no worries, we will make the site accept addresses via GET url parameters"

Me:"Why not make a simple page with input fields that just behaves like the site calling our site via POST?"
Devs:"Nah we don't need that. Will be fine. We will ensure that POST service works via unit test."

Come release week... Dev:"Guys, POST isn't working, IT Analyst tested with the other site..."
Dev1:"Why did QA not test this earlier?"

Dev2:"He wanted to, we told him that we would unit test this. He fucking knew it. He fucking knew it so don't blame him!"

Me: :3

Seriously though, since so many devs I know rant about their QA / test engineers, what would your ideal Test engineer look like?!

I mean sometimes I feel like devs expect test engineers to write them their unit tests too...

Just started a new job at a big co.
Expected to implement small new feature, no sweat about 30 LOC. Unfortunately no unit tests, no way to test without real data.

Spend 2 weeks trying to get it to run on the test rack. Lo and behold the entire testing system has been sitting broken for months and nobody knew. Why is all the documentation so vague!???

Unit test for the sake of humanity

Me When someone writes Unit test: Unit test is good, keep writing

Me when I have to write Unit test: FUCK OFFF

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

Writing unit tests on a weekend and catching up on work that needs to be done because I m too busy on weekdays to have time to think about this...

The sad thing is test coverage is shit in the entire code base as boss just decided to start enforcing requirements now... And I have this huge migrating from legacy system project that needs to be merged. And we'll the legacy system is even shittier

So I have to write unit tests for shit code that was never written with testing in mind...

On the other hand I reworked some testing utilities to make it easier... For everyone... I want a huge bonus.... That I probably won't get...

I'm so sick of "senior/lead" developers pretending they know how to write tests and ending up with these unmaintainable test suites, full of repetitions and incomprehensible assertions.

You should take some time to learn from your mistakes instead of just continuing to write the same shitty tests as usual!!!

Every time I arrive at a new team I spend weeks just trying to understand the test suites for what should be fairly SIMPLE applications!

UNIT TESTS SHOULD TEST UNITS OF CODE!
If your unit test tests seem to be repetitive, they are not unit tests. Repetition is expected in integration tests, but that is why those are usually DATA DRIVEN tests!!!

Every time I try to write a unit test I seem to write an integration test instead. 🤦
I'm just awful at it.

ignoring a broken unit test suite. although ive just convinced the tech lead to let is look into getting it working again.

!RANT

Oh, the SORROW that is JEST! 😡

Endless days have been swallowed by the abyss in my quest to configure Jest with TypeScript and ECMAScript modules instead of CommonJS. Triumph seemed within my grasp until - BAM! - suddenly the tool forgets what "import" or "export" means. And the kicker? On the CI, it still runs like nothing’s amiss!

Allow me to elucidate for the uninitiated: Jest is supposed to be a testing safeguard, a protective barrier insulating devs from the errors of their peers, ensuring a smooth, uninterrupted coding experience.

But OH, how the tables have turned when the very shield becomes the sword, stabbing me with countless, infuriating errors birthed from Jest’s own design decisions!

The audacity to reinvent the whole module loading process just to facilitate module mocking is mind-boggling! Imagine constructing an entirely new ecosystem just to allow people to pretend modules are something they're not. This is not just overkill; it's a preposterous reinvention of a wheel that insists on being a pentagon!

Sure, if devs want to globally expose their variables, entwining everything in a static context, so be it. BUT, why should we, who walk the righteous path of dependency injection, be subjugated to this configured chaos?!

My blood boils as the jestering Jest thrusts upon me a fragile, perpetually breaking system, punishing ME for its determination to support whole module mocking! A technique, mind you, that I wouldn’t touch with a ten-foot pole, because, you know, DEPENDENCY INJECTION!

Where are the alternatives, you ask? Drowned in the abyss, it seems! Why can’t we embrace snapshots and all the delectable integrations WITHOUT being dragged through this module-mocking mire? Can’t module mocking just be a friendly sidekick, an OPTIONAL add-on, rather than the cruel dictator forcing its agenda upon our code?

Punish those clinging to their static contexts, their global variables – NOT those of us advocating for cleaner, more stable practices!

It’s high time we decouple the goodness of Jest from its built-in bad practices. Must we continue to dance with the devil to delight in the depth of Jest’s capabilities?

WHY, Jest, WHY?! 😭

When your project has no unit tests and you just accept that it's non testable anyway. Especially because the company won't put any effort into making a test environment for it.

Trying to unit test legacy code with lots of static methods suuccks!

"You'll be doing X, and be sure to test everything you do. But we don't do unit testing. They aren't paying us for that."
- PM to intern coming via college (it's like a forced internship that counts as another subject for the degree).

I just want to use Jest to unit test my Typescript classes, but that appears to be impossible!
Testing the compiled Javascript instead doesn't seem to recognize any classname at all :(

unit test apologist: what’s your fetish?
Me: I like curves. You like that?
unit test apologist: no, I like…

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?

One of the founders of my startup does not write tests....

Me: we have to all write tests. I explain unit tests, integration, etc.

Him: I do... I have a test that checks if the app crashes or not.

Me: that is not what I meant (writes test because he won’t) 🙄

If this unit test were a real person, I'dsmack it across the face with a steel pipe and shatter its spine with a spiked mace coated in acid. Then I'd toss the fucker into a pit full of a hundred angry, rabid weasels and snarling, hungry raccoons, sprinkle some ground chestnuts and cocaine and tell bastard to run until I see some goddamn green.

*Executed maven build*

Me: What's this "no tests found?"
Senior: Nevermind it's not important. Just check if your code works.

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!

Counted it out... 100k LoC frontend & backend... Not a single automated test. No unit testing, no integration testing, nothing. I've been asked to implement a CI server.

Halp

I just wondered... Is it even possible to write unit tests for an OS kernel or a bootloader?

How would you do that?

I wish i could mock you
and TEST you ..

Don't know about unit test

Me when I complete the actual coding implementation and have to write Unit Test cases:
" AND NOW MY WATCH ENDS HEREEE! "

If your unit test has a bunch of mocked up dependencies which you puppet to do whatever the fuck you want. Something could be improved perhaps

- write a test at a lower level if possible where the dependencies can be abstracted away, or you pass down what you need from them
- write a higher level integration test, i.e. which uses real spring context instead of mock dependencies

But my senior tells me that a unit test will almost always mock all of its dependencies, it should only test the logic in it's tiny atomic piece of work. Mock everythign else out.

Devrant, how do you unit test? I'm looking to learn more on the topic and hear how others do it.

Commit messages:
1- Defect 6380: fix update of user without end date
2- Defect 6380: fix update of user without end date 2
3- Defect 6380: forgot unit test
4- Defect 6380: fix test
5- Defect 6380: dammit!
6- Defect 6380: raaaaaah!!!!
7- Defect 6380: kill me now

Today I read a great article on mutation tests, how to use and why they are important. It looks like a great thing, but...
I have never wrote any unit test in any of my jobs. Nobody in my workplace does that. And now it seems like 100% test coverage is not enough (I remind you, that I have 0%), they all should mutate to check if the quality of unit tests is high.
It seems that I'm left behind. I played with tests in my free time, but it seems the more you write them, the better you get at it, so I should be writing them in my job, where I code most of my time. Not only that, of course, I would also want to ensure that what I'm working on is bug-free.
Still, it will be impossible to introduce unit tests to my project, because they are novelty to the whole team and our deadlines are tight. The other thing is, we are supposed to write minimum viable product, as it is a demo for a client, and every line of code matters. Some might say that we are delusional that after we finish demo we will make things the right way.
Did any one of you have a situation like this? How did you change your boss and team's mind?

I recently started to use automated tests for everything and it is really great to not worry about every little change anymore.
But I think I'm not very good at it. The tests themselves are quite slow and I'm not sure if I'm covering everything the right way. Also, I'm very slow at writing the test cases.
SO I want to learn more about it. Do you have any recommended books on this topic? Anything about unit or feature tests and TDD, language specific (PHP) or general is appreciated

So you're working on a product that basically the main thing it does is fire off http requests and parse their responses into a nice model. We've made some nice helper class that allows you to do this easily, but a simple piece of functionality is not in there yet.

You agree to add this one simple function and decide to:

- Not conform to coding standards set by the team
- Document its behavior which does NOT match the implementation
- Not write a single fucking unit test to prove it's functionality

ARE
...
YOU
...
FUCKING
...
MAD?!

Programming is like getting a crush.
When you couldn't turn her on, you never figure out why.
Even if you did it, you still cannot believe why it could succeed all in a sudden.

The first time you did a unit test
is when you asked if she is okay
for a date; step by step,
In order not to break.
First, ask if she is free; Then, if she really need to eat,
she said OK there.

But, finally she didn't turn up
Integration test failed.
She was such a bitch.

And here I am again, reading test cases that basically boil down to:

$testCase->foo = "bar";
$this->assertEquals($testCase, "bar");

$testCase2->foo = null;
$this->assertNull($testCase2->foo);

Why would anyone feel the need to write these kind of tests? They don't do anything. If I set up my mock a certain way, of course I will have that data, esp. if the unit under test only applies the data AS IS. (Funily enough through another component that already has the relevant dummy tests in place making these tests extra redundant and obsolete.)

You would think that one test case with dummy data suffices, yet no, there are like 30 examples that lie to you about apparent business logic cases, yet in the end the way you set up the mock decides what you will or won't get.

What's the point?

I want to use the DevRant community for a Unit test.

Inspired by Memento, I will make a tattoo ... but ... I want it encrypted. I know nothing about encryption.

I want to make some encrypted messages and I want you guys to decrypt them.

If I'm gonna put something on my wrist for life, it should be secure