Code review titles by year:

1990 - your code is using to much memory
1995 - your code is not running on window 95
2000 - your code is slow
2003 - your code don't have tests
2005 - your code is not 64 bit
2009 - your code is not using mvc patters
2010 - your code is not horizontal scalable
2011 - your code should be written in js
2015 - your code is not mobile ready
2020 - your code is racist

One of my worst meetings, as the sheer rage was unbelievable.

Backstory:
Architect: "Stop duplicating code", "stop copy pasting code", "We need to reuse code more", "We need to look at a new pattern for unit tests" etc.

Meeting:
Architect: What did you want to talk about?

Me: I built a really simple lightweight library to solve a lot of our problems. Its built to make unit testing our code much easier, devs only need to change a small bit of how they work.

Architect: I like the pattern a lot, looks great ... but why a library? can we not just copy the code from project to project?

... do you have a twin or something?

My worst nightmare:

it's not the code what's wrong during testing.

It's the unit tests themselves

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

Had a PR blocked yesterday. Oh god, have I introduced a memory leak? Have I not added unit tests? Is there a bug? What horrible thing have I unknowingly done?

... added comments to some code.

Yep apparently “our code needs to be readable without comments, please remove them”.

Time to move on, no signs of intelligent life here.

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

Python. Changed a function to return a tuple instead of one value in some database code. Tests pass, gets deployed, everything works. End of the month comes. Suddenly, we get a report that we're draining people's bank accounts and credit cards.

It turns out there was an untested bit of code inside the billing process that used this function. It used the function that was changed. To make matters worse, when the exception was thrown, the billing had already completed successfully, and due to another unrelated bug it would retry despite this.

So, needless to say, type safety and good unit tests are things I prioritize nowadays.

Automatically generate unit tests for all the code I write.

CTO: "You must write good tests with high coverage, ideally use TDD. We need confidence in our releases."
Also CTO: *Secretly commits code changes directly to master at 3am, breaks tests, skips CI, publishes, tells no-one*

Writes code.
Doesn't work as intended.
Debug.
Works as intended.
Tests other scenarios.
Don't work as intended.
Debug.
Works as intended in scenarios.
Scenario 1 fails.
Stares at code.
Staring doesn't work as intended.
Fuck...

I am serious. In 1 month, I wrote 32451 lines of code.

- 960 functions
- 189 unit tests

You know what's fucking scary?
If you change a big block of code and it compiles, all tests are passed and you don't even get a warning.
Just wasted 20 Minutes because I tried to look for a mistake

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

Manager: Hey how come you left so many comments on my PR?

Dev: Well you’ve just recently learned how to code so there’s going to be a lot of things to learn beyond what you’ve picked up in your online coding tutorials. Don’t worry it’s only minor things like you put everything all in one function, left outdated comments in the code, have if statements 4 levels deep, have a console.log after every line of code some of which log .env variables, skipped error handling, cast to “any” a bunch instead of using more specific types, didn’t write any tests and some unrelated tests are now failing due to a circular dependancy.

Manager: THAT IS SO DISRESPECTFUL!!APPROVE MY PR IMMEDIATELY. IT WASN’T EVEN EASY FOR ME TO CREATE THE PR, NOW I HAVE TO MAKE AN UPDATE!? YOU’RE THE DEV, YOU SHOULD FIX IT NOT ME!! NEVER COMMENT ON ANY OF MY PRS AGAIN.

As a Java developer, reasons to kill other programmers:

- static mutable variables
- WRITING to static mutable variables
- API call with Framework X didn't work. Add Framework Y along with X and try that. Wrap X in try/catch statement. Catch block fires framework Y.
- six, seven, ten levels of nested code. Zero thought put in organization
- 6K LOC Java files
- spring (singleton? Maybe) object assigning values in static mutable (see pt.1)
- a couple of unit tests in code base that no longer work. Zero unit tests in new code
- unit testing disabled in CI pipeline
- empty catch blocks
- pass mutable data between threads. Modify in various places concurrently.

Boss: I wrote some tests and there is a bug in your code but I cannot find it. Fix it
Me: Sure. I'm on it.

Narrator: 5 minutes later

Me: Boss, I found the bug. It's in your testcode...

Seriously... WTF?!

(before someone suggests that my code should handle all test cases... He tried to measure the time the program needed to response and fucked it up...)

Writing more infrastructure than product.

Look, my application requests and transforms data from a single external API endpoint, it's just one GET request...

But I made an intelligent response caching middleware to prevent downtime when the parent API goes down, I made mocks and tests for everything, the documentation is directly generated from the code and automatically hosted for every git branch using hooks, responses are translated into JSONschema notation which automatically generate integration tests on commit, and the transformations are set up as a modular collection of composable higher order lenses!

Boss: Please use less amphetamine.

Refactoring and writing tests for code that was code written by intern and is on production about one year

My code broke for no reason.
I added a log statement to see why.
*tests code*
It worked....
What the 何?!

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.

Saw this from a friend of a friend of a friend and made my own meme.

2 unit tests 0 integration tests. Hacky code to fix it.

Believing that I don't need to write tests because my code is bug free. 😐

The rants I read here make me want to be a better developer. I started writing tests, linting code and ensuring 'quality code' because of the devrant community. Being a self taught developer, you never really have anyone to thank. But today I would like to appriciate you all for the rants, comments and advice that make us developers become better at our craft.

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.

Bonus points if the person asking me to write tests is a direct contributor to the feature and he's low-key asking me to cover his code.

FUCKING FUCK JAVASCRIPT AND IT'S FUCKING 10000 DEVDEPENDENCIES.

LET ME FUCKING CODE AND WRITE TESTS AND NOT SPEND FUCKING ONE FUCKITY FUCK WEEK TRYING TO FIGURE OUT HOW TO FUCKING MAKE MOCHA AND KARMA PLAY WITH FUCKING ES6 CODE YOU FUCKING FUCKTARD PIECE OF SHIT TECH.

I NO LONGER FUCKING KNOW WHICH PACKAGES I FUCKING NEED AND WHICH I FUCKING DON'T FUCKING DUMBFUCK FUCKWIT OPEN AND HACKABLE MY BROWN ASS PIECE OF TECHNOLOGY STACK.

User: “I’ve tried hundreds of different names. How come all the usernames are registered?!😤”
Developer: ”I’m quite confident about my code. Can’t find any issue in this login form.🤔”
QA: “It passed all unit tests. We did a comprehensive testing on live server by registering all the possible names. What can go wrong?🙀”

During code review:

Guy (also the same guy who pushes code without making unit tests): "Hey, this thing you added is unnecessary. Remove it."
Me: "Have you read the rest of the changes? It isn't unnecessary."
Guy: "Not yet"

how the qa tests my code

Me: *opens up a test script*
> only http response code is checked

Me: hey, coleague from qa, why didn't you also write response body checks?

Col: I had then implemented but removed them later.

Me: ?? Why??

Col: because tests were failing

Crickets: *chirp chirp* .... *awkward pause* [in high pitched crickety voice] what the fuck?!?!

That feeling when you refactor that spaghetti mess into clean beautiful code that passes all tests flawlessly

47 tests passed for Cracking the Code Interview questions.

Time for a drink.

When I discovered Clean Code, design patterns, TDD and BDD. It just clicked. Ever since everything build so easy and obviously. I no longer have most of the code problems folks rant here about.

That's when it came to me: it's not enough to know how to write code. To climb off those amateur shoes I must adopt those methodologies, so that the code would be decoupled from me, from my style, and I've got to let tests drive my code rather than vice versa to have a flexible and reliable codebase that is cheap and easy to maintain/extend.

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

That moment when you write 200 lines of code and it compiled, runs and passes all tests.
Sweet Jesus!

If you make students take coding tests/quizzes on paper, don't grade them on picky syntax errors! We don't code on paper in the real world; syntactic highlighting and red squiggles will usually show you that you accidentally typed that declaration incorrectly. Understanding programming concepts is much more important than being able to write a program on paper.

Dev: My VM is not working. Something is wrong with VM.
Me: Have you made any changes to the code?
Dev: It shouldn't matter my VM is not working.
[I go and check the Dev's VM.]
Me: ಠ_ಠ The build output literally states your unit tests failed

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've been fired today and somehow it was an relief :)
As I know that I am pretty much the only one who knows how the infrastructure works and I am the only one who actively tried to get the company to a better level of coding (tests, code reviews, proper deployment / continuous integration,...) It somehow feels like that gif.

How I spend my days at work working with legacy code:

* Writing tests before I do anything
* Noticing that i cannot write tests because of antipatterns. Lots of them.
* Refactoring to make at least a tiny bit testable.
* Then writing tests.
* More rewriting and refactoring
* Finally adding that one feature my boss asked me for
* Writing tests for that new feature (my do that before implementing)
* Explaining to my boss why it took me so long and agreeing on stopping writing tests.
* 2 days later: explaining why i still broke something.

But in the end my code works just fine.
my colleagues handle things differently. They just ignore problems as long as at least one feature works a bit.

After running tests, code review, coverage test ... And your application crashes in the middle of a demo in front of your PM and your coworkers.

Coworkers : "When you try your best but you don't succeed ..." (Coldplay song)

PM : DAMN SON! WHERE'D FIND THIS ?

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"

Staying up all night writing tests trying to get 100% code covfefe

The lead dev left the company two weeks ago. His last hurrah involved committing a bunch of complicated code into our API. The code he writes is generally overly coupled but this particular code is INSANE.
It is so coupled that the tests for it almost mock the entire application end to end. I only found this heap of garbage when the deployment tests were hung after I made a simple change in a totally unrelated file. THEY DIDNT FAIL. JEST GOT INTO A STATE WHERE IT CANT CONCLUDE AND HAS NO ERROR MESSAGES. We are taking about entirely different parts of the code. As far apart in the code as it can get. It took six hours of playing Sherlock Holmes to figure out what was breaking.

He got the most junior developer to approve the garbage PR as well.

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.

Dev: Ok refactor this following block of code to make it more readable/maintainable while still ensuring the tests pass

*** Block is an absolute mess of nested ternaries, poorly named functions, single letter variables and outdated comments. An underhand pitch if there ever was one ***

Interview Candidate: Why would you refactor code if the tests are already passing?

Dev: …… NEXT.

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!

Boss: Any idea why ColleagueX's code might be blowing out the memory?

Me (internal): Cos he's a fucking retard who can't code for shit, doesn't listen when I tell him to do stuff properly because he's fucking lazy, has no idea what stack and heap are, uses goto everywhere, doesn't know how to debug, doesn't write any unit tests, and generally WASTES MY FUCKING TIME!

Me (external): Probably a memory leak. I'll take a look.

I think I'm falling in love. With TDD.

I used to be very skeptic about it. You know, the usual reasons: it takes longer to deliver, constant "flow" interruptions, etc, etc. But ever since I've tried it I'm nothing but happy about my choice :)

I'm moving forward, I'm not making any regressions, I'm no longer afraid to make any changes in my code as I know tests will show what exactly I break,.. And most importanty, I have all use-cases with corner-cases defined and "explained" in the code... No more do I have to search in Confluence for how this exact scenario should behave. Everything is here. Everything's in the tests.

It's amazing!

Yeah, it DOES take longer to deliver so if you're hardcore Agile living by "Ship it as soon as it compiles" TDD might be too slow. But if you prefer knowing when your code is covering all the use cases w/o any errors -- TDD is the way.

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

I saw this on the first page of a book that discusses techniques for writing clean code... The more I think about it, the more accurate it tests.

Tests!

Before you write a piece of code, write tests which will check that the code does what you expect. This helps you in two ways:

1. It forces you to think about and understand the purpose and aim of the code you're about to write before you start hacking away at it.

2. You know when you're finished, because the tests will pass.

Me: I think we should implement some kind of unit tests.

Lead: No time everything will take twice as long.

* some of my code accidentally breaks some of his *

Lead: I think we should implement some kind of unit tests...

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 couldn't fix the test so I commented it out."

"I removed build timeouts because our jobs started taking that long."

Next I'm waiting for "Compiling the code is good enough we don't need tests" before I lose it...

+ “I’m drunk, but I can still drive.”
+ “I’m tired, but I can still finish this piece of code.”
+ " I don’t need a silly seatbelt.”
+ “Tests? Naw, I’ll just push this to the Master branch.”

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

Just joined a new team at the organisation as senior dev.

Team lead keeps singing about how we need unit testing and good standards.

I implement domain pattern on the backend supported by unit tests.

It passes QA and then get an earful about the code not being 'restful'. What does that even mean?

Well, it matters not since team lead changes the whole feature in the release branch and all unit tests obviously fails. Builds start to fail.

The solution? Comment out all unit tests. In the sprint retro, we hear the same old adage 'we need 80% code coverage'

Do as i say, not as I do. FML.

What do I say to tests that are running against buggy code, you ask?

Our CTO doesn't believe that tests improve code quality. We have no tests on any level, no testers/QA, no code reviews. Nada. I wonder why production keeps breaking 🤔 Guess I'll start looking for another job 🤷‍♂️

Some days you write your code and it all goes well.

All your tests pass, you write clean code, you solve your problems nicely.

Other days everything that can go wrong, will go wrong.

...the latter was the case for me today.

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

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.

Read source code and unit tests. Don’t bother documentation cause it’s outdated. Dig into the core, look where data goes in and where it gets out. Everything else is just a wrapper.

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.

Confession: In my almost 10 years of professional dev experience, I have never written any kind of units tests for my code. Ever.

21 lines of business logic (including whitespace and comments)

9 lines of build config

386 lines of tests (and tests for the tests)

This whole corporate numbers game is killing me. I know I'm getting paid to do what I'm asked, I know. But the metrics are so one dimensional

You fixed the data of 20 tests? Doesn't count because you didn't code
You implemented a function to reduce recurrent failures in the future? Doesn't count because those already pass with time consuming workarounds
You spent half a day communicating and coordinating across teams to fix an issue? That's 1 test, this other person changed 1 line in 5 files, you're 4 tests behind

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.

Python and java tests in college? Both on paper, so you can only write your code once, using a pen, and you can't debug it or modify it. Awesome right... Smh

The fucker complains when someone doesn't write unit tests, meanwhile he tops any new code he writes with a @codeCoverageIgnore annotation ... 😒😒

I have a lab at uni where my lab group have to refactor some code from an open source project. We got assigned some Apache project and jfc that code is a mess. Little to no documentation, hard to navigate, tests that you have no idea what it's testing, and so on. On top of that the teacher expects us to spend more time than we have on it. I'll be glad when this course is over :))

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.

The ability to understand every codebase immediately to the point where I:
* don't need to rely on the documentation
* know exactly where bugs are
* know how a change (bug fix, new feature, etc.) affects other areas of the project recursively

Obviously because it's a waste of time hunting that occur when modifying a codebase, no matter how carefully one writes tests or tests their code, something could always sneak in because it's not always apparent how a change ripples through your codebase.

It's tiresome and especially annoying when working with core modules

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

Great.

I have a demo in an hour for which I need to make some final code changes and tests (about half an hour’s work), and just discovered that XCode killed itself. 🤦🏻‍♀️

Looks like I’m missing the demo.

TDD.

I'm a fan of writing tests right after you write every module. I actually think it's doable.

But I'm not a big fan of traditional TDD, which is defined as: first writing the tests, making them fail, writing code until tests don't fail.

My experience with traditional TDD when writing library code is that you start with this very naive idea of what is needed, so you write classes and functions and a lot of times they look like overly simplistic pseudocode.

So what do you do? You scratch that, you delete those classes/functions several times.

I think this discovery process that your code is naive is slowed the fuck down by doing TDD.

I'd rather write a theoretical API in a readme file, then write code, and then write the tests, you can even withhold writing the tests, but never leaving them for another day, just so that you don't waste time writing tests that you're going to scratch.

There's always a time constraint, and most of us can't afford bikeshedding.

Traditional TDD feels like an esoteric thing, it tries to make programming a series of steps, it actually sounds like an infommercial.
"FOLLOW THESE 3 SIMPLE STEPS AND WRITE THE BEST CODE EVER"

One of our juniors was adding a feature and made a small mistake in one of their (copy-pasted) unit tests by forgetting to cast a return value of a mock

So he spent a ton of time changing the main code to do type checks, try/catching and error handling.

Poor soul realized the mistake in code review one day later

Just went out from a 12+ hours session of debugging.

After removing bits of code until there was almost nothing left, sweeping through StackOverflow, step-debugging into thousand-lines framework source code, running tests, considering filing a bug to Android...

turns out I had a
getFragmentManager()
that should actually have been
getChildFragmentManager().

Today I was writing Selenium tests and was struggling to find a good way to test a text editor. We did a weekly code review and my team lead rewrote the test ij 10 lines to generically handle all cases.

Hopefully I'll be a good dev someday. 😔

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

I seen a dev disable failing integration tests that started failing after his code change

"Let the developers consider a conceptual design,” the King said, for about the twentieth time that day._

“No, no!” said the Queen. “Tests first—design afterwards.”

“Stuff and nonsense!” said Alice loudly. “The idea of writing the tests first!”

“Hold your tongue!” said the Queen, turning purple. “How much code have you written recently, anyway?” she sneered.

“I won’t,” said the plucky little Alice. “Tests shouldn’t drive design, design should drive testing. Tests should verify that your code works as it was designed, and that it meets the customer’s requirements, too,” she added, surprised by her own insight. “And when you drive your tests from a conceptual design, you can test smarter instead of harder.”

"We've refactored most part of the code to follow best practice. Many of the unit tests are broken. Please help us to fix them all".

Me: Oh joy!!!

In my three years experience so far I can honestly say that 100% of the developers I've worked with are narrow sighted with regards to how they develop.

As in, they lack the capacity to anticipate multiple scenarios.

They code with one unique scenario in mind and their work ends up not passing tests or generates bugs in production.

Not to say I'm the best at foreseeing every possible scenario, but I at least TRY to anticipate and test my code as much as possible to identify problems and edge cases.

I usually take much more time to complete tasks than my colleagues, but my work usually passes tests and comes back bug free. Whereas my colleagues get applauded for completing tasks quickly but end up spending lots of time fixing up after themselves when tests fail or bugs appear.
Probably more time wasted than if they had done the job correctly from the start. Yet they're considered to be effecient devs because they work "fast".

Frustrating...

So the juniors finished a feature and it's okay, it passed all tests.

Now I'm cleaning their code and... I opened up a whole file with trash code that is either repetitive, or not even used. I decided to save it in case it breaks one of the features but... nope, everything seems to be running perfectly with just half of the code they wrote.

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

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 long for the day I get a job with an actual developer team, where I can do things like getting my code reviewed or pair programming or being forced to write better tests.

Working as the only developer (or a team of 2) sucks :(

Me: Startup initialization tests fail so the system won't boot properly it until we fix those issues.

Manager: comment out the lines of code that are causing problems.

🤔 So we are just going to feed power to some hardware and see what happens I guess

Bugfix: 1 line of code

Apply bugfix within tests: 60 lines of code

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.

Hours lost.

Visual Studio test adapter was failing out during the discover phase of the tests with a stack overflow exception, but that's all the information it gave me. The tests simply would not run.

Hunting through the code line by line, I eventually find this.

WHY IS THIS ALLOWED TO COMPILE

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

No wonder my Python code was broken. I called the super function of the wrong ancestor 🙄 Lesson learned: run the tests after every functional change, no matter how trivial it might seem.

Being a Dev has its perks.

Started working a couple hours ago (yep, on a Saturday night) to get some code working for a demonstration of a system prototype on Monday.

The code in question was some recursive directory traversal tied in with some file generation in NodeJS. 2 hours later I nailed it, and the feeling of satisfaction of having that code working on all of your tests is overwhelming.

It's a different kind of excitement compared to sitting behind your desk at the office.

Boss: Where should i put this piece of code so the android app will work correctly?
Me: Maybe here and we run some tests.
Boss: What? You built the app so you have to know where I should write the code for the endpoint and your app will work. No time for tests. And no update.

Fuck you boss.

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.

I fucking hate adding unit tests to code that I didn't write

Forgot to change code in my api for rate limiting, after development. No unit tests.. because who really needs that right? 🤦‍♂️🙅‍♂️🤷‍♂️lolololol

Long story short, API went to production eventually, and stopped working almost immediately. Rate limiting was set for 2000 requests in a 1 hour time period. Not my finest moment.. fml 🤦‍♂️

I live in lines of code, broken environments, and tattered tests and you want to know how it's going...
every 30 minutes...
all day every day..
for a week.

And now I am attempting a GTA V hack to explode this Program Managers phone into his thick corporate skull.

Wish me luck
Project_Engineer >= 🍀=💩:= 🖕

delete unused code according to IDE

unit with context tests now fail

what is a good alternative industry or career instead of software development

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

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

Finished writing a microservice in NodeJS. Wrote tests, had clever optimisations, did profiling, the works. Lead dev says to me on a Friday evening to port my code to Java in 2 days. (Reason: to standardize everything) #FML

There is always that one guy.. who doesn't give a fuck about testing and thinks he's not responsible for them...
Le Guy: lemme just push ma new code maan
Jenkins: Unit Tests failed - pls fix
Le Guy to the one who cares about testing: hey fuck uu, ur stupid tests are failing... fix them its ur problem.
*sigh*

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.

I just found a 980 line long method in one of our legacy code bases.... And I need to add to it. There are no unit tests and I desperately want to refactor that shit....

So yeah, apparently there is a drawback of covering your code with tests.

It becomes too scary to execute them because 1 of those 310 tests might fail. Seeing that not all the tests are green - that could be a nightmare.

Every time I run my tests I look away. There's just too much tension.. The more tests - the scarier

*Completes unit testing training*
*Achieves fresh perspective*
*Looks at game code*
*Prepares to right unit tests for that problem method*
*Stares at code as crickets chirp*

aahh, that's a nice feeling!

Half a year ago I was borrowed to a client's team as a pair of helping hands on one project. Today I pulled that project source again to see what has changed.

The only things changed in my code are typos in strings (missing space, missing letter, etc.). Not a single error in actual code.

Maybe >90% TDD tests coverage has smth to do with it ;)

aahhh, that's a nice feeling :)

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 abhor timed code tests. Do you really want to test how fast I can write crappy code?

When you do a deploy and none of the tests fail and you get more suspicious of the code than when a couple of them do fail.

This is not joke but fact

More than a year ago I write code without tests, I must confess its frustrating trying to debug without proper testing. testing is painful I must admit but you can't compare the confident you have on your code with the pains when writing tests.

About a year ago I wrote a whole software without tests and this words from a friend hunted me everyday till date he said, what cannot be tested cannot be trusted. Wise words.

Testers in my team have been told like 1000 times to follow the style guides that we all follow. That's not that big a deal. The big deal is that they were put on this project without having any mathematics background when the project is all about geometric stuff. So after me as a developer having to put so many hours to explain to them why the tests are not covering the requirements or why the tests are red because they are initializing the data completely wrong, I ask them pretty please to do the checks for the coding style and I have already been 4 hours reviewing code because not only I have to go through the maths and really obscure testing code to ensure that the tests are correct, but every line I have to write at least 4 or 5 style corrections. And some are not even about the code being clean, but about using wrong namespaces or not sticking to the internal data types. For fuck shake, this is embedded software and has to obey to certain security standards...

An area of my company hired a new director who directed his “DevOps” team to implement a process that would prevent the CI server from running tests on a PR unless the code was reviewed first. He was worried that there would be too many tests executing with 400 developers committing code frequently.

He’s from Yahoo.

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.

Code coverage

There is some gratification in writing tests and finding corner case flaws in your code. Don't worry past me, present me's tests got your back.

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

Did a big refactor with no tests and the code works first try 🤔🤔

This year I want to become a better programmer. I ordered the book clean code and want to focus on writing more and better unit tests.

If anyone has any tips on how to improve or how to get tips on your code

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

all that decades spent on debuggers, strict typing, static analyzers, fucking unit tests
ima put frogs in my code so they eat bugs
S̸ ̶T̶ ̵O̴ ̴N̵ ̶K̶ ̸S̷

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

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.

I don't know why they made so many algorithms, data structures and big O questions during interview, when all they wanted me to do was to maintain some legacy, tight coupled, spaghetti code with no architecture, documentation, tests nor any kind of engineering behind :/

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

My colleague told me today that companies with shit code quality, complete chaos, no tests of QA of any kind, and poor security practices still make loads of money and are extremely successful so it's all a waste of time.

I detest this idea and I refuse to work like that anymore. But I also think he's right :(

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.

Focus on projects, not tests.

If you want people to be able to code, judge them by their ability to code.

Plus that way your graduates have a portfolio as opposed to a grade list that says nothing about their usefulness in the market.

If you must do tests, at least mimic real world conditions:

- Digital, no paper
- Internet allowed (have rules on copying SO if you must)
- BYOD, let people work in their customised environment

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

Hardest thing for me as Team leader is to teach people in my team, that task is done, when unit tests are written, pull request is created, approved and merged.

Not when their code compiles for a first time.

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

After writing ~200 lines of code and then unit testing it

THE TESTS ALL PASS!!!

then I run them again just to be sure and they all pass but mocha is saying I am getting 40ms lag on some of my tests...

Noooo!!!

This is meant to be an async message passing system; I cannot have an input lag of 40ms :(

! Rant

Today i had to revisit my code to change some functionality for an application i made 3 years back.

I wish i could go back in time, refactor the code and write Unit tests.

Typical Git work flow on a feature branch:

Commit#1 : The silly feature itself that took 10 minutes to code
Commit#2 : Added unsaved files
Commit#3 : Fix unit tests
Commit#4 : Fix
Commit#5 : Fix
Commit#6 : Fix
Commit#7 : Various Fix
Commit#8 : Added unsaved files
Commit#9 : Merge
Commit#10 : Fixed unit tests
Commit#11 : Code Review tasks
Commit#12 : Revert- Code Review tasks
Commit#13: Refactor part 1
Commit#14: Refactor part 2
Commit#15: Deleted unit tests
Commit#16: Added checking for null
Commit#17: Completely different feature's bugfix
Commit#18: Code review spacing corrections
*Approved*

Trying to merge, then merge conflicts.....

Too much technical debt
Write more unit tests
Unit tests failing, the code will be right so change the tests to pass
Too many unit tests to maintain, they look a lot like technical debt
Remove unit tests to reduce maintenance overhead

When one of your tests breaks, do you rewrite the test, or the code?

Usually I rewrote the test.

Fix the Unit Tests to pass your Code!

Was trying to figure out why the code coverage tool always reports 0% on my android tests. Turns out that is specific to newer samsung phones and it reports the coverage correctly on other phones.
Good old samsung, annoying devs since 2009!

That moment when first coding challenge is a mathematical expression evaluator with custom unary operators but your code does not meet the standard because it did not cure cancer.

The fuck you mean I had no unit tests. You specifically told me that you don't want a lot of code. F@$#&#k

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

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

The moment you realize that you have successfully beaten reality with your unit-tests...

There are unit-tests for ...
... the api returning a 408 Http StatusCode when an internal request times out.
... the react app take this status-code and fires an action to display a specific error message for the user.

Every bit of code runs just fine.

Deploy this hell of an app on the server. Dandy Doodle.

Do a smoketest of the new feature.
FAIL!
Chrome starts to crumble during runtime. The api Request freezes.
Firefox takes the 408 api response but fails to interpret it in react app.

So I began to wonder, what the hell is going on.

Actually I recognized that I had the glorious idea to return a clientside error code in a serverside api response.
Glorious stupidity :/

Finally I fixed the whole thingy by returning an 504 (Gateway timeout) instead of 408 (Clientside timeout)

Cheers!

Fixed a high priority bug today just prior to release. There was 100% test coverage. The tests pass both before and after the change. The product behavior is correct now where it wasn't before. Just one more reminder that test coverage does not equate to either quality or correctness. Tests are alarms (at best), and quality of tests are no better an any chunk of code. All tests have costs, but not all have value. All reasons why I am skeptical of the value of code coverage, TDD, or anything that posits that "all tests are good".

Any code should be simple and easy to read / understand.

I just reworked an old stored SQL proc.

Went from 102 lines to ... 10.

More I code, more I realize that maintainability, readability, comments and unit tests are more important than actual code. (And performances ofc. But if 1 line code does it in 1 second and 500 lines code in 0.2 seconds, I’ll take one line solution every time)

Because of all the devRant posts about unit tests, I decided to write a few to see how they worked.
They just saved me from pushing completely broken code to production. THANK YOU devRant!!

Just had a class where we had to write a heap adding algorithm in Java to reduce rounding error for x amount of floats being added together

After an hour of writing code with no testing anything I finished. Ran the JUnit tests provided by the teacher and it passed all the tests!

Who says it can't work the first 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 :(

Feeling good, code compiled but failed tests :(

Yeah, sure. Send in your code for review with THE UNIT TESTS YOU WROTE FOR YOUR CODE FAILING!

I still don't know how I feel about programming tests here in my university being on paper. Literally, we code on paper and that's it. Teacher corrects it like a compiler.

When you know you should be writing your tests first, then your code. But you secretly do it the other way round anyway.

Write code. Write tests. Everything passes and you go home happy. Come to work next morning, run tests again just to be sure. Everything fails.

Why fucking my coworker push not compilable code on master branch??

Ok we are developing it, no yet release but I can't compile it for my tests.

From the book

Refactoring JavaScript
Turning Bad Code into Good Code
Evan Burchard

HOW CONVERSATIONS ABOUT REFACTORING SHOULD GO UNTIL TESTS ARE WRITTEN
“I refactored login to take email address and username.” “No, you didn’t.”
“I’m refactoring the code to ____”
“No, you aren’t.”
“Before we can add tests, we need to refactor.” “No.”
“Refactoring th–”
“No.”
“Refa–” “No.”

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

You had two additional weeks to improve your project.

You could research different marketing strategies to increase revenue. You could add some new features to attract more users and ensure your existing users are satisfied. Finally, you could optimize performance to make your UI quicker.

But you’ve chosen to write some unit tests. Now that two weeks are gone, you got no new features, no performance improvements and no new marketing strategies while your competitors got them all.

Tests caught obvious bugs that can even be caught by static typing, but you by definition couldn’t write tests that’ll catch unpredictable bugs, so they are still present.

After six months you realize you have to rewrite a major part of your project because your project (surprise-surprise) has to chase market needs to stay relevant. Your tests are thrown into trash along with your old code.

“Having trouble with code quality? Write a lot of tests. And I mean a *lot*. Test every file in isolation. Mock as many imports as possible.

When you're done, your code will still be bad, but now your tests will make sure it's impossible to improve anything in any meaningful way.”

Not leaning on unit tests. I usually write them after testing my code manually, and lose time for testing feature by hand.

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.

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 can't make progress on my private project.
I just started and already refactoring my code.
Yesterday I started to refactor my tests -.-'

I'm sure I will lose the interest in this project because I start a new one I can refactor to death.

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.

Yo dawg, I heard you like writing code for code you already wrote. So I made you write some mock functions so you can write code for code you already wrote!

To be able to actually write useful tests BEFORE starting to code, which I guess is really asking for the ability to have a clear set of requirements and a complete mental model of the problem at hand

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*

We had a project where we had to code in c# and setup a continuous integration server and create some tests for our application.

Our teacher asked:"Are you guys using junit?

He was serious.

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

Maybe im wrong but still, damn policies, at my job i need a code review and a commit review before committing code and Im ok with that but hell, I was required to run the api tests when I only modified 2 front end file, i mean seriously i need to run c# tests after modifying angular components. It just seems silly and foolish and a complete waste of time to run the tests for all the projects when i didnt even modified one.

If you work with me and know who I am then stho and accept it. :p

When you are new to a technology and language, but have to make full use of its feature.
You know, make tests, implement production code, planning deployment, build a CI. All by myself.
No regrets, though. Challenge accepted!

All code and no tests makes a software buggy, hard to maintain and a pain in the ass to work with.

Sometimes, I run tests just because I want a break from writing code. In good cases it's so that I take a moment to think about what I'm going to do next. In most cases however, I'm struggling for motivation

TFW the mock class has way more code than the real one.
Testing big infrastructures can be a pain...
Or maybe my team is just not so good at it.

My time spent:
Adding new feature to the real class 15%
Extending the mock with the same feature 55%
Writing tests 30%

My road trip still lasts for another 5 hours and my laptop does not have power anymore 😧😧😧

I could refactor or comment so much code. Maybe add even more loggings and unit tests, but noooo 😔

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

Always always always always always keep writing tests as you implement features. TDD is good thing but not necessary but tests are really necessary. I thought I'll write tests later now the code is so tightly coupled I can test things independently. 😑😑

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

Use CoffeeScript they said, it will be fun they said.

NO! No, no, no, no!!!

Fuck this.

Converting old library written in coffescript to ES6 is just fucking insane.
I see 1000 lines of code to take me at least several hours if not a whole day.
and tests are yet to come.

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

Chrome likes to count teleporting goats, Android tests if the user is a monkey. I like to put "void fish(object look)" in my code and throw the fish where ever I wanna test something.

What are some interesting functions you've added to your code? Has another dev caught your function yet? (mine hasn't been caught yet, yay!)

Why is the C++ build and package management system so complicated? I feel like whenever I work on a C++ project, I spend more than half my time just figuring out how to set up the environment, build the binaries, run the tests, when I’d rather and should be writing code.

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?

Started working as a "working student" in an it company to write unit tests. (which then will be executed automatically - so automated unit tests)

Realised that I write more or less the same code just changing the names and some parameters (sometimes more if it's not an number but a bool for example but it's pretty much the same scheme)

So I bought a tool for 1$ to use "auto complete" on custom templates.(I type testgetbool and the tool replaces this to the test case only asking for the variable name.)

So now I'm writing automated automated tests 😁😅

(which is btw pretty boring but cost & time effective)

Mini witch hunt going on with broken builds last couple of weeks. Change satellite assembly/project A, breaks random unit test that hasn’t been changed for months and the TFS nazi sends out emails demanding the “broken” projects be fixed. Doesn’t matter the unit/integration tests are likely out dated and team responsible for the tests needs to fix it.
Yesterday I deleted some logging code out of a security assembly, broke an integration test that hasn’t needed to be ran since January (test database didn’t exist anymore).
I would have had to re-create the database, re-import the test data (not trivial), re-deploy a service using the test database…blah. All because I removed some logging code.
I deleted the gated check-in TFS build definition. Code check in … no sirens …whew! I win!

You know what I hate? Git commit messages stating 'fixed tests' or 'fixed docs' or 'fixed integration problems'. You did not fix anything, fuckhead. You updated the code, introducing more bugs as usual. FIXED?! NO, UPDATED! That's what I hate.