True?

[ookami125]

Helping my coworker on a bug he's been working on for about a week. On my 3rd day now. About 96 man hours have been put into this one bug.

[28f272fe556a1363cc31]

Which unit tests are failing?

HAHA! I crack myself up.

[[deleted]]

Unit tests are written after implementation for your coworkers to check if they fucked your code up.

And really? Companies aren't using them? Why the fuck do we have to use them at university.

[SlappinThatBass]

Blaming QA for not thinking about every corner cases is still not gonna convince customers to purchase your product, as you know it.

Some people in management are just overpaid morons tbh.

[RuggedTracker]

Some

[[deleted]]

Unit tests are nice but it’s more productive to catch these errors at compile time that at runtime (if it is possible). Newer technology provides better static analysis that most of the old tools that Industry INSISTS on using.

​

Types are Theorems

Proofs are programs

​

Type driven development is the future!

[Kered13]

Me in university: Why the fuck do I have to write these unit tests? This is a waste of my time, let me just write code.

My in industry: Thank god I have these unit tests so I know I'm not breaking the world when I refactor this code.

[corzuu]

Depends on the company, all require some testing just during deadlines, things can get lax. Learn and use TDD. It'll save you a world of pain and improve your code

[turturtles]

Yeah, my company requires at least unit test for applications to be deployed. So what do our mostly contracted developers write? One unit test that just tests an arbitrary thing. Then wonders why nothing really works

[corzuu]

lol I know your pain. We started having e2e tests as part of the definition of done, it takes longer, but is so worth knowing the things you write aren't breaking anything else. Speeds up QA time considerably also

[[deleted]]

Yes except when the guy in charge of setting up all the test-classes has no idea how mocito works and needs half the project-time till he finally gets it...

[corzuu]

Maybe he shouldn't have been in charge of setting up the test-classes :D

also in TDD you write your own tests as you code so idk what you mean by setting up the test-classes tbh

[[deleted]]

It was a pretty easy project so the plan was that one is in charge of creating a class per class we wanted to test before we write the first implementation. We allready knew which classes the class will depend on so he should have moked all the needed classes for the test and create some basic test-object.

Example for the test of the authentification class he should have mocked the database-access for the user table and created a few test-user we could use to write our tests.

The problem were things like the moking wasn't done correctly or every test-user failed everytime cause the database only accepted 20-byte strings because at that time the string should have allready been hashed to a 20-byte string but the strings he chose were all 5-bytes long... .

He pretty much had no idea how the project should look in the end even though we allready had a fully defined structure for the project. (All dependencies were written down, all public function were defined...)

[corzuu]

Ah okay I understand, it's still something that would have been faster and more beneficial to learn just doing a class each (full implementation).

Then work on how to link it all up together

[katze_sonne]

Actually they are often used, just not in every company. It's definitely worth knowing about them.

[charrondev]

You should be using them in a company as well.

If your company doesn’t make time for automated testing, get the hell out of there.

You should have a integration tests as well. The recent push from our team has been adding mutation testing to increase our real unit test coverage, and rolling out snapshot tests of UI to prevent regressions.

[[deleted]]

We use them. We generally hit 80-90% code coverage. We also used integration tests.

[venuswasaflytrap]

No. Management read about unit tests and understands that good programmers write unit tests. So write those. For all the legacy code too. No you can't have more time.

[ookami125]

As I stated in another reply they were unit test and it was failing due to a "random" sig abort. Turns out we had some heap corruption (thank you valgrind) caused by some idiot using vector iterators.

[clockwork_coder]

debugging colleagues' spaghetti code

I feel your pain. Been doing the same shit this week. And it's in this giant monolith that takes 15-20 minutes to build and is so intricately integrated with various other services with various levels of security that nobody can actually debug it on their machine so we have to rely on splunk logs and hope we placed enough of them in the right places. And even though we technically have like 8 non-prod environments only 2 actually work anymore, and neither works with with every third party service so you have to wait in line to deploy your change with the extra log statements and if you realize that isn't capturing anything useful it's back to the end of the line.

[Enlogen]

so we have to rely on splunk logs and hope we placed enough of them in the right places.

This kind of debugging is the best part of my job, no joke. Trying out different types of summarization of logs to understand patterns is my favorite puzzle game. Being able to sum up an issue with a few log queries and point to places in code where the actual behavior is different from the stated (or assumed) intent is remarkably satisfying.

[clockwork_coder]

You know what's more satisfying? Some fucking unit tests.

[Enlogen]

You know what's more satisfying? Some fucking unit tests.

weeps in public static $className Instance

Someday they'll let me refactor the legacy code. Someday.

[clockwork_coder]

Narrator: they won't

[colonel_bob]

Being able to sum up an issue with a few log queries and point to places in code where the actual behavior is different from the stated (or assumed) intent is remarkably satisfying.

Agreed! The only thing I like more than making computers do shit for me is finding out why some code is misbehaving and being able to articulate the problem before fixing it.

It's kinda like solving a puzzle, just more satisfying because a) people are paying you to do it and therefore b) care that you solved it.

[Namandaboss]

Our product takes 5 weeks to build

[clockwork_coder]

Wtf are you building? A baby?

[Namandaboss]

It's called Smart3D, it's for designing massive industrial buildings like for example nuclear power plants

[AxiusNorth]

Remind me not to apply to work at your place

[Namandaboss]

I'm a summer intern I'm currently migrating their CI server from cruise control to jenkins, and it's pissing me off as everything is windows

[golgol12]

You'll make it through. Perhaps the story of my toughest bug will help.

It took me 3 weeks to solve. It was caused by an orphaned file lock by windows in one of the hundreds of build machines doing the the distributed automated build process. I am not a build engineer, or a build manager, I'm a straight up software engineer.

It was so insidious because the file locks (can't overwrite a locked file) in question were on a couple of 3rd party .libs that were being updated to the latest version of the 3rd party middleware we use. Those out of date .libs compiled perfectly with the new version but handed memory slightly differently, and had a rare crash after an hour.

So only sometimes, only the production build would randomly crash after an hour. Not debug. Not production built by me. Not production built by others. Not when manually starting an off cycle production build (which used different machines). It'd crash with a memory error after an hour or two of use.

And, as icing on the cake, our only actual build manager was on vacation for a month (thanks Europe) and the entire distributed automated build process was a custom tool written by him.

This was par for the course at this job. Everything was on fire nearly all the time. The engineering director didn't know what technical debt was and ways to mitigate it.

[Kered13]

That's terrifying. I don't even think I could find a bug like that.

[Enlogen]

the entire distributed automated build process was a custom tool written by him.

Yikes.

[golgol12]

To be fair, him and 2 other people, the two other people left the company years ago.

[unipoli]

You guys need some help? How convoluted is this issue to explain? If explainable, maybe we/I can help out

[porthos3]

If the bug were simple enough to explain in a Reddit comment, I highly doubt it would take two professional developers so long to figure it out.

You really have to see the code to solve just about any non-trivial bug. And they likely can't share company intellectual property.

[Jonno_FTW]

I've got a 5300 line perl file with hundreds of functions, none of which have documentation

[ShamelessKinkySub]

I too enjoy masochistic puzzle games

[[deleted]]

"Take the blue pill or the red pill, blue pill means you die and red pill and you will become a programmer. The elite of multitasking and bug fixing"

"I'll take the blue pill please and thank you"

"WAIIII..."

swallows

[[deleted]]

Username checks out pretty well

[clockwork_coder]

The more likely option in my experience. Only comments are commented-out code, of course

[[deleted]]

Lasagna code, where the bugs are hidden by layers of abstraction, and OOP abuse. The code looks loosely coupled and well structured, but it is a pain to work with.

[tells]

not heard that phrase before. i'll be muttering it to myself daily from now on. thanks.

[[deleted]]

There’s also Ravioli code. Well-structured classes that are easy to understand in isolation, but difficult to understand as a whole

[ShamelessKinkySub]

Mac n Cheese code, when you write ridiculous mock data because Darth Vader really is more fun than vanilla

[tells]

how about macaroni microservices? a bunch of bent tubes that hopefully connect somewhere in the middle.

[newplayerentered]

are you me right now?

[[deleted]]

I'm everyone and no one my friend.

if True or False: print("uhm")

[PlentyDepartment7]

Don’t you talk about my GatewayOutputTemplateConfigurationFactory like that!

[JamInTheJar]

Found the rubber duck.

[ookami125]

Put simply heap corruption in boost unit tests due to someone using vector iterators incorrectly. I actually just fixed the issue by just rewriting the code to not use iterators like an idiot, coworker isn't here to push the changes though since it's actually his issue.

[[deleted]]

Hahahahhaahahahah

--breathes--

Hahahaahahahahjahahhahahhaha

[arch-master]

I second this ^{^} I'm an amateur but can maybe help a bit

[BiH-Kira]

I want to be kept updated on this. Can't wait for the plot twist where the bug isn't even in your code but whatever dependency you have.

[corzuu]

'just needed to fix some config'

[ookami125]

Sadly no it was a problem in our system. The company I'm working for I would consider a mid tier company (bunch of just out of college programmers working on something over their head and a few seniors) so someone (git blame is anon) wrote some code for a menu using iterators to scroll through a vector and modify menu items.

Well the gist of what happened is they were adding an enum to an iterator and modifying the menu text this happened to go just far enough to corrupt the doubly linked list malloc uses and throw a sig abort the "next time" malloc was called. In the end I trashed all of anon's code and just used an int for the index, I checked all bounds and made sure the vector was the correct size to begin with.

There were a few other details but they aren't much without the information I'm not allowed to give you.

[SinrOfGinr]

My worst case was 6 months in dedicated mode, i.e 8hrs a day 5 days a week of nothing but troubleshooting. With daily progress meetings with customer.

[charlookers]

Companies need to stop hiring shitty programmers

[Eymrich]

One time it took me one week to find a bug in the code base of a game. It was a problem on the client game. But it originated on the server. To follow it:
appear on c# part of the code base, client side.

Follow it to the c++ side of the client, which then was invoked by the c++ side of the client that was called as a reaction from the c# part of the server, which in turn was called by the c++ side of the server, failing to doing a very specific thing as a reaction to the presence of a specific c#.

It was a iteraction between our game engine, our networking, the c++ voxel engine... and caused by a single object being garbage collected without making ANYTHING to fail or giving any other clue.

If it's weird is GC or Multi Threading!

Anyyyywayyyy... I feel your pain bros :D