1. Buy boxes of orange juice, almost past their expiry date.
2. Put boxes on the hot office windowsill for a few weeks.
3. Cool down juice in fridge.
4. "Hey dear coworker, would you like a refreshing juice box on this hot spring day?"
5. Watch coworker retch and vomit, spitting blue-grayish juice over his desk, crying: "Why would you give me old moldy juice without checking the date?"
6. "Do you remember when you told me you didn't have time for unit tests? THIS IS WHAT HAPPENS, DAVE, THIS IS WHAT FUCKING HAPPENS WHEN YOU DEPLOY UNTESTED CODE.... NOW FINISH YOUR JUICE!"

Boss: "I looked at a testing suite. It is $2,500 a license and I'm buying 60 licenses. You should probably get familiar with it."
LeadDev: "Um, we already use NUnit, and it's free."
Boss: "Hmm...I'd better add Pluralsight training in the budget so you can learn about the new program."
LeadDev: "Oh, no...we need new laptops more than we need software."
Boss:"New laptops? Not my budget. When we buy this new software, everyone is going to use it"
LeadDev: "Everyone? How will you monitor it's usage?"
Boss: "I'll have networking send me captures of all the running tasks on the dev machines. The test suite better be running. Writing good tests will be our #1 priority."
LeadDev: "Um, we already write tests using NUnit."
Boss: "I don't understand what you are saying. I need something I can visualize. This UI testing suite is exactly what I need."
LeadDev: "Maybe the testing suite would be better suited for you and QA?"
<click..click>
Boss: "Submitted the budget. There will be a test server available for you to configure. This whole project costs over $100,000, so don't screw it up. Any questions?"
LeadDev: "Oh...well...what server ..."
Boss: "Dang...sorry, I'm taking off the rest of the afternoon. We'll talk about this more on Monday. Get started on those Pluralsight videos. I'll expect a full training and deployments by next week. Have a great weekend!"

After listening to two of our senior devs play ping pong with a new member of our team for TWO DAYS!
DevA: "Try this.."
Junior: "Didn't work"
DevB: "Try that .."
Junior: "Still not working"

I ask..
Me:"What is the problem?"
Few ums...uhs..awkward seconds of silence

Junior: "App is really slow. Takes several seconds to launch and searching either crashes or takes a really long time."
DevA: "We've isolated the issue with Entity Framework. That application was written back when we used VS2010. Since that application isn't used very often, no one has had to update it since."
DevB: "Weird part is the app takes up over 3 gigs of ram. Its obviously a caching issue. We might have to open up a ticket with Microsoft."
Me: "Or remove EF and use ADO."
DevB: "That would be way too much work. The app is supposed to be fully deprecated and replaced this year."
Me: "Three of you for the past two days seems like a lot of work. If EF is the problem, you remove EF."
DevA: "The solution is way too complicated for that. There are 5 projects and 3 of those have circular dependencies. Its a mess."
DevB: "No fracking kidding...if it were written correctly the first time. There aren't even any fracking tests."
Me:"Pretty sure there are only two tables involved, maybe 3 stored procedures. A simple CRUD app like this should be fairly straight forward."
DevB: "Can't re-write the application, company won't allow it. A redesign of this magnitute could take months. If we can't fix the LINQ query, we'll going to have the DBAs change the structures to make the application faster. I don't see any other way."

Holy frack...he didn't just say that.

Over my lunch hour, I strip down the WPF application to the basics (too much to write about, but the included projects only had one or two files), and created an integration test for refactoring the data access to use ADO. After all the tests and EF removed, the app starts up instantly and searches are also instant. Didn't click through all the UI, but the basics worked.

Sat with Junior, pointed out my changes (the 'why' behind the 'what') ...and he how he could write unit tests around the ViewModel behavior in the UI (and making any changes to the data access as needed).

Today's standup:
Junior: "Employee app is fixed. Had some help removing Entity Framework and how it starts up fast and and searches are instant. Going to write unit tests today to verify the UI behaivor. I'll be able to deploy the application tomorrow."
DevA: "What?! No way! You did all that yesterday?"
Me: "I removed the Entity Framework over my lunch hour. Like I said, its basic CRUD and mostly in stored procedures. All the data points are covered by integration tests, but didn't have time for the unit tests. It's likely I broke some UI behavior, but the unit tests should catch those."
DevB: "I was going to do that today. I knew taking out Entity Framework wouldn't be a big deal."

Holy fracking frack. You fracking lying SOB. Deeeep breath...ahhh...thanks devRant. Flame thrower event diverted.

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?

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

I delivered a small C# program long time ago.
Unit tests, integrations tests, functional tests, all passing (users even happy).

Colleague of mine approached me.

C: "I finally fixed the program"
M: "Which program?"
C: "Product X"
M: "What was wrong with it?"
C: "Nothing, but now it runs on Python"
M: "..."
C: "Yeah, we lost a few features, but it's Python!"
M: "Aren't you busy with other things?"
C: "That can wait"
M: "..."
M: "..."

New senior dev joined the project today.
Senior dev: "There's no way for me to test my changes before I merge this into develop"
Me: "Can you at least run our test suite?"
An hour later the develop branch is fucked and everyone who has merged it locally has pages of red errors splattered across their screens whenever they run any tests.
Start looking into what the fuck is going on.
Notice that all the errors are related to changes the new guy made.
Ask him if he ran the tests..
Senior dev: "Nah they wouldn't catch anything locally "
Stare at the stream of red text running down my screen.
Normally I wouldn't care but we were trying to prepare a release... RUN THE FUCKING TESTS ASSHOLE.

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.

Client: so how could we test this 😬
Me: you know what, send me an email at linuxxx@companyname.com and I can look if I can properly reply! Keep in mind though that this is for one time only, no further questions through that email address!
Client: Yes of course! *sends email*
Me: *tests* - *works fine* - *messages client back through the ticket system*
Client: *proceeds to send two follow up questions to my fucking work email address*

Me: *selects emails* - *marks emails as spam and deletes them*

Fucking seriously?! Cunt.

Summing up many ridiculous meetings I've been in.

Many years ago we hired someone for HR that came from a large fortune 500 company, really big deal at the time.

Over the next 6 months, she scheduled weekly to bi-weekly, 1 to 2 hour meetings with *everyone* throughout the day. Meeting topics included 'How to better yourself', 'Trust the winner inside you'...you get the idea.

One 2-hour meeting involved taking a personality test. Her big plan was to force everyone to take the test, and weed out anyone who didn't fit the 'company culture'. Whatever that meant.

Knowing the game being played, several of us answered in the most introverted, border-line sociopath, 'leave me the frack alone!' way we could.

When she got the test results back, she called an 'emergency' meeting with all the devs and the VP of IS, deeply concerned about our fit in the company.

HR: "These tests results were very disturbing, but don't worry, none of you are being fired today. Together, we can work as team to bring you up to our standards. Any questions before we begin?"
Me: "Not a question, just a comment about the ABC personality test you used."
<she was a bit shocked I knew the name of the test because it was anonymized on the site and written portion>
Me: "That test was discredited 5 years ago and a few company's sued because the test could be used to discriminate against a certain demographic. It is still used in psychology, but along with other personality tests. The test is not a one-size-fits-all."

VP, in the front row, looked back at me, then at her.
HR: "Well....um...uh...um...We're not using the test that way. No one is getting fired."
DevA: "Then why are we here?"
DevB:"What was the point of the test? I don't understand?"
HR: "No, no...you don't understand...that wasn't the point at all, I'm sorry, this is getting blown out of proportion."
VP: "What is getting blown out of proportion? Now I'm confused. I think we all need some cooling off. Guys, head back to the office and let me figure out the next course of action."

She was fired about two weeks later. Any/all documentation relating to the tests were deleted from the server.

Doot doot.

My day: Eight lines of refactoring around a 10-character fix for a minor production issue. Some tests. Lots of bloody phone calls and conference calls filled with me laughing and getting talked over. Why? Read on.

My boss's day: Trying very very hard to pin random shit on me (and failing because I'm awesome and fuck him). Six hours of drama and freaking out and chewing and yelling that the whole system is broken because of that minor issue. No reading, lots of misunderstanding, lots of panic. Three-way called me specifically to bitch out another coworker in front of me. (Coworker wasn't really in the wrong.) Called a contractor to his house for testing. Finally learned that everything works perfectly in QA (duh, I fixed it hours ago). Desperately waited for me to push to prod. Didn't care enough to do production tests afterwards.

My day afterwards: hey, this Cloudinary transform feature sounds fun! Oh look, I'm done already. Boo. Ask boss for update. Tests still aren't finished. Okay, whatever. Time for bed.

what a joke.

Oh, I talked to the accountant after all of this bullshit happened. Apparently everyone that has quit in the last six years has done so specifically because of the boss. Every. single. person.

I told him it was going to happen again.

I also told him the boss is a druggie with a taste for psychedelics. (It came up in conversation. Absolutely true, too.) It's hilarious because the company lawyer is the accountant's brother.

So stupid.

Looks like I'm getting fired on Wednesday :)

Long story:

*I add first unit tests to project.

*Boss adds new functionality and breaks all the tests so I can't compile and write more for what I'm working on.

*Boss is very fragile and cannot handle any comment that can possibly be taken as a slight against him.

Me: "I wanted to ask what our policy on unit tests is please? Because we haven't really said how we are treating unit tests, and everyone myself included is not thinking about them. I also haven't added tests when I fixed bugs and this time your changes broke the tests"

Boss 10 minutes later: "I want to speak to you in private".

Boss: "you are too forceful and direct. You said I should have added tests."

Me: "yeah but I didn't mean in a nasty way"

Boss getting louder and more aggressive: "You are too forceful"

Me: "I didn't mean it in a bad way"

Boss: "I didn't want to add tests for that!"

Me: "then why add any tests?"

Boss: "Fine we are not having this conversation now!"

*Boss storms out

I decided I can't speak to the guy about anything without upsetting him spoke to the manager before I quit because I can't work like this.

That resulted in a meeting with my boss, his boss and the head of HR where I ended up savaging him and told them I can't bring up anything as I can never tell if it will offend him and that I spend ages writing emails and trying to document communications because I just can never tell if I will upset him. Also that I cannot bring up any ideas because I can't tell if he will somehow get offended and that I can't even write code because if I change something he wrote at some point he will get angry.

My boss claims that I am extremely forceful and disrespectful and that I am constantly insulting him and his decisions.

We go back over a ton of shit and I refute everything he says. In the end I have to have a meeting with him on Wednesday where we either get things straight, he fires me or I quit.

I think at this point that our relationship is too fucked for him to be my team lead on a 6 man team.

Side note I keep bringing forth ideas because we have one database shared between 6 Devs, no pull requests (apart from mine and another new guy), no test driven development, no backlog, no team driven story pointing, no running tests before merging, no continuous integration setup, no integration tests, no build step on merge, no idea of if we are on track to our deadline other than his gut feeling, no actual unit tests backend - just integration with a test db, no enthusiasm to learn in the team and no hope.

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.

At one of my former jobs, I had a four-day-week. I remember once being called on my free Friday by an agitated colleague of mine arguing that I crashed the entire application on the staging environment and I shall fix it that very day.

I refused. It was my free day after all and I had made plans. Yet I told him: OK, I take a look at it in Sunday and see what all the fuzz is all about. Because I honestly could fathom what big issue I could have caused.

On that Sunday, I realized that the feature I implemented worked as expected. And it took me two minutes to realize the problem: It was a minor thing, as it so often is: If the user was not logged in, instead of a user object, null got passed somewhere and boom -- 500 error screen. Some older feature broke due to some of my changes and I never noticed it as while I was developing I was always in a logged in state and I never bothered to test that feature as I assumed it working. Only my boss was not logged in when testing on the stage environment, and so he ran into it.

So what really pushed my buttons was:

It was not a bug. It was a regression.

Why is that distinction important?

My boss tried to guilt me into admitting that I did not deliver quality software. Yet he was the one explicitly forbidding me to write tests for that software. Well, this is what you get then! You pay in the long run by strange bugs, hotfixes, and annoyed developers. I salute you! :/

Yet I did not fix the bug right away. I could have. It would have just taken me just another two minutes again. Yet for once, instead of doing it quickly, I did it right: I, albeit unfamiliar with writing tests, searched for a way to write a test for that case. It came not easy for me as I was not accustomed to writing tests, and the solution I came up with a functional test not that ideal, as it required certain content to be in the database. But in the end, it worked good enough: I had a failing test. And then I made it pass again. That made the whole ordeal worthwhile to me. (Also the realization that that very Sunday, alone in that office, was one of the most productive since a long while really made me reflect my job choice.)

At the following Monday I just entered the office for the stand-up to declare that I fixed the regression and that I won't take responsibility for that crash on the staging environment. If you don't let me write test, don't expect me to test the entire application again and again. I don't want to ensure that the existing software doesn't break. That's what tests are for. Don't try to blame me for not having tests on critical infrastructure. And that's all I did on Monday. I have a policy to not do long hours, and when I do due to an "emergency", I will get my free time back another day. And so I went home that Monday right after the stand-up.

Do I even need to spell it out that I made a requirement for my next job to have a culture that requires testing? I did, and never looked back and I grew a lot as a developer.

I have familiarized myself with both the wonderful world of unit and acceptance testing. And deploying suddenly becomes cheap and easy. Sure, there sometimes are problems. But almost always they are related to infrastructure and not the underlying code base. (And yeah, sometimes you have randomly failing tests, but that's for another rant.)

My favorite kind of interview question/challenge is anything that is highly practical for the job. At the current company I work, the coding test/interview challenge was to design and implement an API very similar to the core functionality of the actual product. It’s fair, tests for skills relevant to the job, and is much better than irrelevant silly brain teasers and cs questions, I feel.

In terms of specific questions, one of my favorites is one that one of my colleagues suggested I ask to potential candidates: describe what you think your biggest failed project/task was in your engineering career, and what happened/what you learned. I think it’s a good reflective question that can tell a lot about someone.

So what does everyone think about unit tests, do you do it?

My own experience is I've seen people on my current team disable failing tests...

Me: *Installs travis*

Dev: oh what's travis?

Me: it's a continuous integration tool I wanna setup.

Dev: ... contin.... ?

Me: continuous integration, a tool that performs builds.

Dev: ah!, is it the new version of that deprecated tool we were using "client access"?

Me: ... no ... that's an authentication service that generates and stores oauth tokens. This is the continuous integration tool I told you about yesterday (and last week and the week before).

Dev: ... contin....

Me: ... con ........ continuous integration. It listens to branches on GitHub, downloads, builds, tests and then deploys the code.

Dev: ah ok ok, cool.

I would bet my monthly fucking salary he can not repeat what I said, tell me what oauth is, or explain what he's working on at the minute.

Jesus at this rate I'd bet my salary he can't tell me my name.

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

I'm convinced code addiction is a real problem and can lead to mental illness.

Dev: "Thanks for helping me with the splunk API. Already spent two weeks and was spinning my wheels."
Me: "I sent you the example over a month ago, I guess you could have used it to save time."
Dev: "I didn't understand it. I tried getting help from NetworkAdmin-Dan, SystemAdmin-Jake, they didn't understand what you sent me either."
Me: "I thought it was pretty simple. Pass it a query, get results back. That's it"
Dev: "The results were not in a standard JSON format. I was so confused."
Me: "Yea, it's sort-of JSON. Splunk streams the result as individual JSON records. You only have to deserialize each record into your object. I sent you the code sample."
Dev: "Your code didn't work. Dan and Jake were confused too. The data I have to process uses a very different result set. I guess I could have used it if you wrote the class more generically and had unit tests."
<oh frack...he's been going behind my back and telling people smack about my code again>
Me: "My code wouldn't have worked for you, because I'm serializing the objects I need and I do have unit tests, but they are only for the internal logic."
Dev:"I don't know, it confused me. Once I figured out the JSON problem and wrote unit tests, I really started to make progress. I used a tuple for this ... functional parameters for that...added a custom event for ... Took me a few weeks, but it's all covered by unit tests."
Me: "Wow. The way you explained the project was; get data from splunk and populate data in SQLServer. With the code I sent you, sounded like a 15 minute project."
Dev: "Oooh nooo...its waaay more complicated than that. I have this very complex splunk query, which I don't understand, and then I have to perform all this parsing, update a database...which I have no idea how it works. Its really...really complicated."
Me: "The splunk query returns what..4 fields...and DBA-Joe provided the upsert stored procedure..sounds like a 15 minute project."
Dev: "Maybe for you...we're all not super geniuses that crank out code. I hope to be at your level some day."
<frack you ... condescending a-hole ...you've got the same seniority here as I do>
Me: "No seriously, the code I sent would have got you 90% done. Write your deserializer for those 4 fields, execute the stored procedure, and call it a day. I don't think the effort justifies the outcome. Isn't the data for a report they'll only run every few months?"
Dev: "Yea, but Mgr-Nick wanted unit tests and I have to follow orders. I tried to explain the situation, but you know how he is."
<fracking liar..Nick doesn't know the difference between a unit test and breathalyzer test. I know exactly what you told Nick>
Dev: "Thanks again for your help. Gotta get back to it. I put a due date of April for this project and time's running out."

APRIL?!! Good Lord he's going to drag this intern-level project for another month!

After he left, I dug around and found the splunk query, the upsert stored proc, and yep, in about 15 minutes I was done.

* Updates and adds unit tests *
* Runs unit tests *
* All tests pass *

What the fuck? I'm not THAT good to write tests that pass on the first iteration.

* Runs unit tests *
* All tests pass *

Someting's not right here.

* Checks terminal *

FUCK I'm in the wrong project folder

Every 2 months without fail:

Manager: I don’t understand what the point of writing tests is. They only ever pass and when they fail we just fix them so they pass again! It’s completely redundant!!! An exercise in absolute futility!

Dev: …

Always deliver the goods.

Even if who you work for are idiots, and the product is useless. You never know who will see what you've done.

- I did a six-month underpaid project for ShittyCompany.

- Strived to write it nice and clean with unit tests and good(barely) documentation.

- Got a call up a year later from a consultancy company who integrated with the application I wrote. Now I work for them, and it's as close to my dream job as I could hope for.

One month ago. By email.

Boss: so, this client A has a problem with one of our devices and he believes that it's a bug in the software.

Me: all right then, what happens?

Boss: well, he says that the parameter P in the option menu does not changes the device's behaviour as it is supposed to. I'll forward you his mail. You will find attached an excell file with the results of his test performed with and without the parameter active.

Me: < read mail, read excell file > well, boss, his tests are performed in completely different conditions, how could he expect to infer a meaningful results from this?

Boss: damn, you are right. Send him a test plan and follow up.

Me: < send detailed test plan >

No answer in a week. Then...

Client: hi, there, I made this tests, I attached the excell with the results, can you check the software now?

Me: < read another bullshit filled excell file with none of the suggested test performed >
You know what? Just download the procedures you are using from the device and send them by mail, specifying the software version you are using so we can perform some tests here in the lab and get yo a solution asap.

No response. For a MONTH.

Super Boss: client A still has his problem, how could possibly be that it takes more than A FUCKING MONTH to solve his issue??

Me:...

One component is used over 30,000 times. How many unit tests do you think we have for it? Zero. Fucking zero, Zip, Zilch, Nada, None.

WHAT THE QA FUCK!?

Product Owner: "need this doing in 6 months, can you do?"
Me: "we're too busy to start another project at the moment - can you wait about 6 months for it to start, or I'll have to hire more devs"
PO: "I'll just outsource it"

36 months later the company he outsourced to is out of business and hasn't delivered, and I've had their half-finished shit show git repo dumped on me.
No comments, no docs, and no units tests, so no fucking idea what it's supposed to do

"We need to reduce the scope of the project, guys... What if we don't make tests? They're taking some time do write, so..."

Yep. Let's compromise the quality and call it scope reduction. It will make wonders to our roadmap 👍

Client: "I did not receive the email that should be send after that event. Please fix."
Me:
* Checks code - ok
* Tests feature in locally - ok
* Tests feature in production - ok
* checks values in database - ok
* 2 hours wasted - ok
"Please help me dear CTO, idk what else I could check or how I should even respond to this."
CTO: "hmm, the clients account uses a adminstrative email address for testing. Let me just check if it is in the mailbox."
*checks* "Yeah, that's the email you're looking for, right?"
Me: *experiences relief, anger, blood lust and disappointment at the same time* "Could you please respond to the client for me, I need a break. Thanks"

For a week+ I've been listening to a senior dev ("Bob") continually make fun of another not-quite-a-senior dev ("Tom") over a performance bug in his code. "If he did it right the first time...", "Tom refuses to write tests...that's his problem", "I would have wrote the code correctly ..." all kinds of passive-aggressive put downs. Bob then brags how without him helping Tom, the application would have been a failure (really building himself up).
Bob is out of town and Tom asked me a question about logging performance data in his code. I look and see Bob has done nothing..nothing at all to help Tom. Tom wrote his own JSON and XML parser (data is coming from two different sources) and all kinds of IO stream plumbing code.
I use Visual Studio's feature create classes from JSON/XML, used the XML Serialzier and Newtonsoft.Json to handling the conversion plumbing.
With several hundred of lines gone (down to one line each for the XML/JSON-> object), I wrote unit tests around the business transaction, integration test for the service and database access. Maybe couple of hours worth of work.
I'm 100% sure Bob knew Tom was going in a bad direction (maybe even pushing him that direction), just to swoop in and "save the day" in front of Tom's manager at some future point in time.

This morning's standup ..
Boss: "You're helping Tom since Bob is on vacation? What are you helping with?"
Me: "I refactored the JSON and XML data access, wrote initial unit and integration tests. Tom will have to verify, but I believe any performance problem will now be isolated to the database integration. The problem Bob was talking about on Monday is gone. I thought spending time helping Tom was better than making fun of him."
<couple seconds of silence>
Boss:"Yea...want to let you know, I really, really appreciate that."

Bob, put people first, everyone wins.

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

Comments for 'why', unit tests for 'what'

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.

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?🙀”

When my boss asked me to write tests. Here is what I said... :P

I jump on an existing scala project.

git pull && sbt compile test

Tests are failing.

Me: "Hey team, the tests are failing."

Team member: "That cannot be. They were passing for the the last run."

Me: "Did you run them locally?"

Team member: "No, on Jenkins. It was fine."

I check Jenkins.

Me: "What do you mean it's fine. The last successful deployment was on the end of May."

Team member: "The Pull Request checker always went through successfully."

I check how our Jenkins tasks are configured. It's true that the Pull Request Checker runs successfully yet due to a "minor misconfiguration" (aka "major fuckup") the Pull Request Checker only tests a tiny subset of the entire test suite.

Team members were were fine if their Pull Request got the "Success" notification on bitbucket's pull request page. And reviewers trusted that icon as well.

They never checked the master run of the Jenkins task. Where the tests were also failing for over a month.

I'm also highely confused how they did TDD. You know, writing a test first, making it green. (I hope they were just one specific test at a time assuming the others were green. The cynic in me assumes they outsourced running the tests to the Jenkins.)

Gnarf!

Team member having run the tests locally finally realizes: "The tests are broken. Gonna fix them."

Wow. Please, dear fellow developers: It does not kill you to run the entire test suite locally. Just do it. Treat the external test runners as a safety net. Yet always run the test suite locally first.

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

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

## 4 years ago:
- Principal Architect: We are using IO1 storage type. What if we used GP2?
- Perf team: IDK, let's test it!
*we run tests*
- Perf team: results are OK, but we're exhausting Burst IO capacity, effectively hard-limiting number of tests we can run per day
- PArch: ahhh, I see. Then Gp2 is a no-go.

## 3 years ago
*PArch quits. New one is hired*
- PArch2: We are using IO1 storage type. What if we used GP2?
- Perf team: We've already tested that a while ago, results were THIS and THAT
- PArch2: I see. Let's test it again anyway
- Perf team: *wtf???*
*we run the same tests, we get the same results*
- PArch2: I see, so GP2 is a no-go.
- Perf team: *you think....? How did that thought never cross our minds, we wonder...*

## 2 years ago
*new DBA is hired*
- DBA2: We are using IO1 storage type. What if we used GP2?
- Perf team: We've already tested that a while ago, results were THIS and THAT
- PArch2: We've already tested that a while ago, results were THIS and THAT
- DBA2: I see. Let's test it anyways. I've read somewhere that GP2 might be a better bet
- PArch2: you might be right, let's do that
- Perf team: *wtf???*
*we run the same tests, we get the same results*
- DBA2: I see, so GP2 is a no-go.
- Perf team: *you think....? How did that thought never cross our minds, we wonder...*

## 1 year ago
*DBA manager left; new one was hired*
- MGMT_dba2: We are using IO1 storage type. What if we used GP2?
- ........

Should we even bother bringing up the history.....?

Was in a meeting today with a team I just joined, I asked what they used to write tests.. they said they don't write tests because no one would see them..

This is crazy right?

You guys should really take a look at your YouTube history sometimes (If you use it). It's amazing how I move from one video to another.

Here is what I did yesterday:

- I watched a GOT Season 7 review
- Then for some reason, I watched Underground nuclear test
- Several HD footages of Nuclear tests
- Top 10 Demolitions gone wrong 😕
- "No Planes" in 9/11 attack 😕
- Amber Heard's Sexy Prank 😕

Fucking hell, I need to get back to work ☹️

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

Had a 1:1 with my boss last night and together we figured out a tricky bug related to my PR. However, either my PR or that bug patch broke a tangentially-related test. Queue my usual exhaustion, and I gave up trying to fix it.

This morning, I'm looking at it and nothing makes sense. My change should not have broken the test. So I reran the controller's tests, and... they all pass?

What is logic.

Good thing, though; that test leads to a few rabbit holes I haven't even begun exploring yet.

Oh, never mind. It broke again.
Ergh, here we go. 😔

We've had a bunch of flaky tests in our repo for a while now that no one could be bothered to fix; we'd just re-run ci until it's green. Today I looked into it and I was inspired to make this meme, because I lived through it.

Adding logs to investigate just lowered the fail rate making investigation more difficult. I do have an idea of what it might be though so, we'll see tomorrow.

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.

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.

There are 2 node js apps floating around the city...built by me for intranet apps used in a logistics company.

I legit asked a friend if it has been replaced and he said no, that they keep on running like a fucking beast causing no issues whatsoever.

Fascinating. I was legit expecting it to crash a while ago.

Guess mern stacks do scale if you know what you is doing.

Write your unit tests people.

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

Unit tests fail.

Re-ran it again without looking at details.

Unit tests pass now.

What. Why?!

Now I can't sleep at night.

boss: we should map all the possible ways to do things in the system so we can test them and make sure we fix the bugs.

Me: yeah, well, that is exactly what automated tests are for, every time we find a non-mapped way that breaks this we make a test out of it and fix, this ways we end up mapping the majority of ways.

Boss: yeah,yeah ... Let's sit down latter and map everything on a document.

I bet my ass we are never gonna have tests as a part of our workflow.

A while back I feel asleep on the couch on the day of the state of the union address.

My deadass mind heard someone asking what the "state of the unit tests" was and I leaped up and said "there aren't any! i'm sorry, it's only a small project anyway".

Thank god no one else was there... 😂

team lead: what is the minimum lenght validation on the first name field?
dev: i decided to put minlenhgt 3
team lead: why? did you tests it
Dev: i tested it. 3 makes sense to me
Team lead: isint your first name 2 letters long?
Dev: oh i dodth think about that

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.

I REALLY HATE TECHNICAL PHONE INTERVIEWS!!!
I was asked: "What are the differences between C++ and Java?"
I got a mind blank at that point... Good thing it didn't last long and I came back with a reply.

But seriously, if you can't speak English clearly, why? Why? WHY?!
(I lost a whole question because I couldn't understand the interviewer. ☹)

At least it went "well" and now I have to improve the "technical" document and do 2 tests by Monday!

Some random coworker has been asked to setup tests for the framework written in Java and the GUI is a web app that comes with the framework.

Since he doesn't know any language we work in, he decided he would do it in Python. When I asked him why introduce Python and he replied with "it doesnt matter which language it is because it is going to run on selenium"

I told him to either use Java or Javascript for selenium because when he leaves we should be able to maintain the tests and not first figure out what the hell you wrote in Python

He didnt understand and is going to go with Python anyway

Boss: "i need you to build a feature so that customers can do bla bla bla and it has to be done by friday.

Dev: "Ok i can do it fast if you sure this is what you want, and requirements wont change in the future. Have you considered bla bla"

Boss: "Yes do it"

Dev: *writes, tests and deploys code*

A few weeks later:

Boss: "we need to add bla bla to the feature you built since some requirements has changed."

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

Creative dev compliments? Wow, that shows what type of person I am. I only know creative dev insults. Okay let me give it a go!

Wow, I'm gonna star that on GitHub!

Good work! I'm gonna put a shortcut to that right here on my desktop (in the same tone as "I'm gonna hang that on the fridge")

You're so meticulous that the unit tests are to make sure the computer works correctly, not your code.

If you were a web server, you'd always return 200/OK.

Your parents must have compiled you with -Ofast

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?

Have you ever had a problem with a partner, but you cannot prove at 100% that he has something against you? But you cannot stand him?

Well, this happened two years ago. I was working as a tester, and “John” (I won’t say his real name) was the dude who tests my tests, but in production.

I ‘m a sociable person, and I don’t mind talking with another people. Suddenly, I noticed that my co-worker started to behave a little bit... rude? Plain? I don’t know, but sometimes he didn’t answer my conversations/questions, or sometimes answered with extra-negative stuff.

“Well, his life is not easy” I said to myself. “Everybody haveproblems”, “I have to understand him and calm down”.

Two weeks later started to report really REALLY absurd production bugs, and with absurd I mean, for example, that he didn’t like the color of a button, a point next to a phrase, etc., things very very simples, but sometimes he ignored big errors.

Once I had to went out of the city for few hours, and asked to permission to go out. I had pending tests, but I left a document with specifications in case of emergency. Even passwords. Before I could finish the thing in the other city, my partner called me two times, and asking me obvious things! I had to go back to the office ealier that I had planned, so f*** angry 😡 and when I arrived to the office, John said “no, forget it, let’s solve it tomorrow” 🙃 WTF?!!!!!!

I decided not to argue with him.

Also noticed that his headaches suddenly increased, and looked so tired ☹️ I felt guilty to judge him

I felt so guilty, and even today I don’t know what to feel about that or what to think. I don’t work there anymore, but, What do you think? What would you do?

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

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.

Once during a standup, I mentioned that I needed to fix some unit tests before the build would be ready. Our tester then said "no time for tests, we need the build now". That was a dark day.

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.

My only nemesis are sales people.
* They try to sell the impossible to the customer.
* They think even the biggest change takes only some minutes to implement, and tests do not even exist.
* They promise to deliver an app within half the time which means we have to cut out animations or some tests to deliver when due.
* They often get a commission (sometimes not as part of profit but revenue!) for calling their pals and asking them if they wanna buy something new (some say they also take the risk, but they don't, the company does).

There may be exceptions, but my perceived ratio between good and bad sales is about 1/20.
Now I am in a very small company with only one sales guy. Guess what, he is a good one! I hope he stays forever.

Me and my team has been creating React components for the last two months. Today we realized that not a single component is done the Redux way (as pure functions), which means we have to refactor every component and the tests.

That's what you get for trying out new technology..

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.

God: you qualify for reincarnation. What advice from past life do you want me to retain in your memory ?
Me: never forget to write those unit tests!

After working 3 years in my current job and my boss hating anything to do with unit testing etc, I used my spare time to refactor our Makefiles to allow for the creation of unit and integration tests. I technically didn't tell my boss about it, so my heart was in my throat when he Skyped me with 'what did you change in ...'?

After having bashed any workflow with testing in it, I showed him the new workflow and automatic testing in Jenkins and he was actually enthousiastic, just like all other employees! I was hailed a hero in the R&D department, after all this time we can finally write universal tests. :D

This begs for a rant... [too bad I can't post actual screenshots :/ ]

Me: He k8s team! We're having trouble with our k8s cluster. After scaling up and running h/c and Sanity tests environment was confirmed as Healthy and Stable. But once we'd started our load tests k8s cluster went out for a walk: most of the replicas got stoped and restarted and I cannot find in events' log WHY that happened. Could you please have a look?

k8s team [india]: Hello, thank you for reaching out to k8s support. We will check and let you know.

Me: Oh, you're welcome! I'll be just sitting here quietly and eagerly waiting for your reply. TIA! :slightly_smiling_face:

<5 minutes later>

k8s team India: Hi. Could you give me a list of replicas that were failing?

Me: I gave you a Grafana link with a timeframe filter. Look there -- almost all apps show instability at k8s layer. For instance APP_1 and APP_2 were OK. But APP_3, APP_4 and APP_5 were crashing all over the place

k8s team India: ok I will check.

<My shift has ended. k8s team works in different timezone. I've opened up Slack this morning>

k8s team India: HI. APP_1 and APP_2 are fine. I don't even see any errors from logs, no restarts. All response codes are 200.

Me: 🤦‍♂️ .... Man, isn't that what I've said? ... 🤦‍♂️

Nightmare IRL:

Your colleague is in PTO for 2 weeks.

You are in charge of maintaining his project along with yours, CI, code, tests and everything.

Your colleague's code base is a real master piece of shit when you look at it closer. By shit, I mean hardcoded values everywhere, random sleeps now and then, 20 if branches that could be replaced by maps, variables named a b c d everywhere, try catch to silence errors that should not be silenced, etc.

Your colleague left the CI and code broken as shit. Takes forever to run on my goddamn computer.

PMs are spamming you: "What is going on? It's red everywhere. Help! Plz fix this! We are going to release tomorrow!"

FML

A few years ago I was in high school and used to have a small reputation of hacking things. I could hack, just would never hack any school networks or systems (reputation + notice that there was a breach is a bad combo since everyone would immediately suspect you).

Anyways one day the networks internet connection went down in the school district and I was the only one who used a laptop to take notes. So I quickly opened the terminal and ran Wireshark and said to the person to my right "see that button there? yeah I programmed this last night. anytime I press it I can shut down the network so the teacher can't reach her files (she famously only saved them online). *Long dramatic press* Wireshark started scanning the network so all the numbers and lines were going crazy as it viewed the packet info "Now just wait", soon the whole class knew what I had done through whispers and lo and behold a few minutes later and the teacher couldn't reach her files.

Everyone loved me for the rest of the year for saving them from the homework for the week the wifi network was out since it also ended up having to cancel two tests in the class, and a lot more homework and tests in all their other classes. Solidified my reputation and no one fucked with me from that day on.

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

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

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"

Realized there was a bug in my npm package that made it hard to update the state of the input field conditionally (rather than explicitly through user action) and fixed it, wrote tests to ensure it was working the way I thought it was, updated the dist, updated the package version, merged, cut a GitHub release...

Then uninstalled and reinstalled it in the project I’m using it in and it didn’t work. What the eff, I think. Take a couple hours furiously trying to figure out why the hell the behavior doesn’t seem to match the behavior of the new version.

Then it dawns on me. I check the package.json.

“react-autosuggestions”: “^2.1.0”

.... I forgot to do the “npm publish” step.

*head desk*

This is getting annoying.

For the past >half a year I've been chasing windmills. This is what my BAU day looks like:

- We login to client's network
- We start running some Sanity tests before the actual runs (actual runs are hell of an expensive (financially and time-wise) thing to launch) to make sure environment is OK.
- Sanity tests fail. wtf? Nothing's been changed since y-day!
- Spend ~3-4 hours digging logs, code, more logs,... Apparently some genius decided to change a single parameter.
- Spend another 1-2 hours trying to work around that parameter (since apparently that genius did have a task to do that, so we'll most likely have to find a way to live with it)
- Restart the whole env (~30min).
- Launch a Smoke, Sanity tests to verify env state.
- Launch the actual test
- Go home.

Next day:
- We login to client's network
- We start running some Sanity tests before the actual runs to make sure environment is OK.
- Sanity tests pass.
- Run the actual test
- Concurrency on RDS database is sky-rocketing! WTF did that come from??? Nothing's been changed since y-day!!
- Spend ~1-2 hours looking for anything changed, dig some logs for anything unusual. Nothing.
- Escalate to DBA. 2 hours later DBA says "fix the app". thanks for nothing mate....
- Spend remaining 2 hours analysing AWR. Give up, restart the whole RDS instance. Another hour wasted.
- Time to go home. Out of curiosity run Sanity test -- all good. Run the actual test -- all good. wtf??
- Go home

Next day
- We login to client's network
- We start running some Sanity tests before the actual runs to make sure environment is OK.
- Sanity tests fail. wtf? Nothing's been changed since y-day!
- Spend ~3-4 hours digging logs, code, more logs,... Apparently some genius decided to change a single parameter.
- Spend another 1-2 hours trying to work around that parameter
- ..... I think you know where this is going.

And this keeps going on and on, day by day. Spending the better half of the day chasing windmills and doing our actual work on the last hour of the working day or even after that.

We have plenty of interesting tasks in our Jira but we're squirels spinning in the wheel and never being able to touch them.

It feels like I'm wasting my time. I could do so much more with my time!

[just needed to vent ]

So, learning Java at the moment.

Thoughts so far:

“This IDE is going to make me so lazy! It can write getters, setters, AND toString() for me?!”

“Oh my god, angle brackets. It’s like someone with a love of nesting was made fun of for wasting space and retaliated by crafting a language that inlined nesting data types.”

“Whoa, this would safeguard what kind of input went into the function SO MUCH.”

“DOES THIS MAKE IT EASIER TO WRITE UNIT TESTS?! *excited*

End user when criticizing a developer for 'taking long' to create something of value from scratch:
(4 hours later): "What's taking you so damn long? Are you retarded?"

Oh I don't know, maybe I have to make sure that tests in my code run well, maybe I have to evaluate everything to meet the custom satisfactions of the user for his ever-so-custom requirements and I also have to make sure I discard what they don't like? And maybe it takes time to deliver a quality product, and so on?
Or would you prefer I deliver an untested product that I didn't bother to think about and I haven't bothered to make sure it matches with their requirements?

What end users don't understand is the involvement in a quality product.

Went to college feeling like I didn't know enough to keep up with the game development course, ended up knowing so much that I tested out of my entire first year and ended up teaching my professors what to do. I got special permission to ditch classes and on several occasions taught the class stoned off my ass. I didn't need to submit homework or take tests. I had my own game studio founded so I was allowed to show off my work as my final project. College was a great time for me lol

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

Why is source code so crappy? May career is not the longest, buy in my 8 years I talked to so many developers and every one told me how important quality, standards, tests and architecture are - but every codebase I've seen is lacking all of it. Everything is running on constant live support.

I don't get it. It is like I live in a world where everyone does know what has to be done, but no-one does it. I suspect it is because people are lazy, lying and won't say no but that's also not a world I want to live in.

Boss: "we're going to take over a project from another company. that's what we know so far - any other questions?"
Me: "do we get the history (svn/git) or just current source? unit tests?"
Other company: "no history for you. no unit tests - app was only tested manually"
Me: *sigh* :'(

Oh, RSpec.

Adding recaptcha tests, I copy a passing login spec
and because I'm bored, I run it again just to check.
I paste in the passing mock
and run it in my new block
and oh no, why are you failing? What the heck!?

I opened an issue on a repo telling the owner that placing a "test passing" badge on the readme but not having other tests than an "ExampleTest" and no tests of the actual functionality is bad practice and what he thinks about updating the readme.

The result was a deletion (not close) of the issue and a ban from contributing (issues, PRs) on any of his projects.

And it was not some small "ten persons use this" project but a large boilerplate project with 2.4k github stars and over 800 forks. You would expect a little bit more professionalism of someone with that popularity.

Today I told 3 devs that they either get their shit together or they can pack their things and look for a job.

I can get easily pissed, but it's rather rare for me to get to that point easily.

Now my dear friends, can you guess what they did?

I give you a hint...

They made a test suite validating a network library.

So we have roughly 200 plus lovely splitted tests, neatly put in a directory structure - lovely organization.

(I might have written in the ticket that as a requirement... Cause I know my lil hellspawns)

But as I started looking at some tests, there was always something missing...

Network library...

So we needed to create an endpoint... And handle of course the tests communication with the endpoint *somewhere*.

I'd guess you know already what these mofos did...

Yeah. We have one class.... That handles all tests endpoints... Via different methods... Plus additional methods like utility functions....

The ticket was easy they said.

Me chewing their heads off was easy too.

Jesus Christ, I really doubt sometimes that some devs are able to go to a toilet.

Maybe thats the reason some wear baggy pants - easier to hide the pampers.

*rolls eyes*

After working on 7 projects last year with 7 different groups and learning to "flow like water", I don't feel the urge to rant anymore. There are always going to be all kinds of weird scenes, cheap clients, incompetent coworkers, people that pretend to know something when they actually know shit. All of those are just tests life is presenting you to make you learn to be peaceful and tolerant.

The world is broken, accept it, and allow yourself to be an ordinary human being, you'll be free and happier. Stuff like the law of attraction does exist. Just learn to be happy and grateful for what you get and you'll get a ton more reasons to be happy and grateful

Was talking about how I implemented CI/CD in one of our projects as a starting point to others and how it worked by running tests and deploying to the server and one of my colleagues laughed about having to have tests at all, I explained and asked him what was he gonna do that morning, his answer:

"Well, I'm gonna test the system X and fix some bugs"

To what I replied:

"If you have automated tests you could have those tests automatic(?!) and they also help you finding bugs early"

Wtf do ppl have in mind that they prefer remediation over prevention and they end up wasting their time with shit that could be fully automated?

Our project at work goes live in 3 weeks.

The code base has no automated tests, breaks very often, has never had any level of manual testing

will not be releasing with any form of enforced roles or permissions in our first release now due to no time to enforce, however there is a whole admin api where you can literally change anything in our database including roles.

We also have teams in various countries all working separately on the same solution using microservices with shared nuget packages and they aren't using them properly.

Our pull requests are so big - as much as, 75 file changes - in our fe app that I can't keep up with it and I honestly have no idea if it even works or not due to no automated tests and no time to manually test.

We have no testing team, or qa team of any sort.

Every request into the system has to hit a minimum of 3 different databases via 3 different microservices so 1 request = 4 requests with the load on the servers.

We don't use any file streams so everything is just shoved in the buffer on the server.

Most of the people working on the angular apps cba to learn angular, no one across 2 teams cba to learn git. We use git so they constantly face problems. The guy in charge has 0 experience in angular but makes me do things how he wants architecturally so half the patterns make no sense.

No one looks at the pull requests, they just click approve so they may as well push directly to master.

Unfinished work gets put in for pull request so we don't know if the app is in a release state since aall teams are working independently, but on the same code base.

I sat down and tested the app myself for an hour and found 25 fe only issues, and 5 breaking cross browser issues.

Most of our databases are not normalised. Most of our databases make no sense. 99% of our tables have no indexing since there is no expertise with free time to do it.

No one there understands css properly. Or javascript.

Our. Net core microservices all directly use ef in the controller actions so there is no shared code there.

Our customer facing fe app is not dry because no tests so it was decided it was better this way.

Management has no idea on code state, it seems team lead is lieing to them about things like having any level of tests.

Management hire devs that claim to be experts but then it turns out they have basically no knowledge of what they were hired to do, even don't know what json is or the framework or language they are hired for, but we just leave them to get on with it and again make prs too big to review.

Honestly I have no hope that this will go well now but I am morbidly curious to watch. I've never seen anything like the train wreck that we are about to get experience.

Product Owner keeps demanding developers do items outside of Sprint, deleted story points to get extra items in, signs off holiday for my staff, even hired some unqualified developers, etc. for my team (I'm the Dev Manager). I'm blessed to report into the PMO who backs up the Product Owner, in front my own reports, meaning I have no authority. What would you do?

PMO has decided that if we drag items from Sprint to Backlog when they reach SIT, we have more space for Dev items in the Sprint :-| Though he expects developers to actually do the SIT work, including writing the SIT tests :-|

58 of 64 tests failed

Me: "what the actual fuck."
*spends 10 mins looking through logs wondering why these valid tests were marked as failed*
Me: "Oh shit I just configured the test case wrong"

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

So... About a month ago 2 interns started a project from scratch at my company. My boss gave them a project to follow as an example (more for the api and database side).

Wednesday they ended the internship and I've began to help fix the rest of the kinks that were left to be fixed. Friday we were finishing up the app and api to send to the client for tests. The database was created with 4 tables that were equal in structure... Imagine that you need a table for orders and they have status like pending, cancelled, finished and accepted. What they've done was they created 4 tables, one for each status....

Why the hell would you do this???

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.

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?

Fucking nice, my damn PC has problems handling RAM and can't stay more than 1 minute in any OS without crashing. Windows bluescreens with MEMORY_MANAGEMENT or other bullshit. Nice fucking situation. It's either my CPU's IMC or all of the four RAM sticks. Long tests say it's not my board. Either way, I'm fucked because I haven't got any money to replace my PC yet.

What a coincidence, I got similar parts to someone on Google+ who lives near me and has this exact problem EXCEPT HE CAN REPLACE HIS PC SOON AND I CAN'T. GREAT.

Okay, this is MAJOR FUCKING BULLSHIT.
I understand variability of, dunno, 10, but 40?
The tests were ran on the same machine, one after another. What the fuck?

What is it with networking guys refusing to do any kind of fault finding? Pretty much everywhere I've worked they seem to be overpaid address hogs who occasionally want everyone to be proud of them for installing a new switch.

Currently seeing a production issue that's clearly due to spikes in packet loss on a certain part of the network - but oh no, it's always "our tests are fine", "we can establish a route no problem", "this is an application level issue", etc.

No you morons, when a dozen unrelated applications hosted on different cloud services fail because none of them can contact anything in your particular subnet in your data center at the same time, it's a damn networking issue. Sort it out.

My current job at the release & deploy mgmt team:

Basically this is the "theoretically sound flow":

* devs shit code and build stuff => if all tests in pipeline are green, it's eligible for promotion
* devs fill in desired version number build inside an excel sheet, we take this version number and deploy said version into a higher environment
* we deploy all the thingies and we just do ONE spec run for the entire environment
* we validate, and then go home

In the real world however:

* devs build shit and the tests are failed/unstable ===> disable test in the pipeline
* devs write down a version umber but since they disabled the tests they realize it's not working because they forgot thing XYZ, and want us to deploy another version of said application after code-freeze deadline
* deployments fail because said developers don't know jack shit about flyway database migrations, they always fail, we have to point them out where they'd go wrong, we even gave them the tooling to use to check such schema's, but they never use it
* a deploy fails, we send feedback, they request a NEW version, with the same bug still in it, because working with git is waaaaay too progressive
* We enable all the tests again (we basically regenerate all the pipeline jobs) And it turns out some devs have manually modified the pipelines, causing the build/deploy process to fail. We urged Mgmt to seal off the jenkins for devs since we're dealing with this fucking nonsense the whole time, but noooooo , devs are "smart persons that are supposed to have sense of responsibility"...yeah FUCK THAT
* Even after new versions received after deadline, the application still ain't green... What happens is basically doing it all over again the next day...

This is basically what happens when you:=
* have nos tandards and rules inr egards to conventions
* have very poor solution-ed work flow processes that have "grown organically"
* have management that is way too permissive in allowing breaking stuff and pleasing other "team leader" asscracks...
* have a very bad user/rights mgmt on LDAP side (which unfortunately we cannot do anything about it, because that is in the ownership of some dinosaur fossil that strangely enough is alive and walks around in here... If you ask/propose solutions that person goes into sulking mode. He (correctly) fears his only reason for existence (LDAP) will be gone if someone dares to touch it...

This is a government agency mind you!

More and more thinking daily that i really don't want to go to office and make a ton of money.
So the only motivation right now is..the money, which i find abhorrent.

And also more stuff, but now that i am writing this down makes me really really sad. I don't want to feel sad, so i stop being sad and feel awesome instead.

Assignment release: this is a basic assignment that is supposed to help you understand the basics of memory allocation. You are free to use any design you want, however you can implement more advanced features that would lean towards specific designs. What will be punished is that you don't have a dynamic memory allocator. We will run the tests for these offline after the deadline

2 days before the deadline: we released the tests for checking whether you're allocating memory dynamically, but these tests also check for this specific design. So fuck you for choosing any other design than this one. Have fun on sleepless nights.

Fuck me, I guess, for worthlessly working on a different design than they wished for, but didn't specifically ask for from the beginning. I just wasted 2 weeks of my life and feel unmotivated af to do anything anymore regarding this. Fuck this shit. Fuck them. Fuck this course.

My new favourite commit message:

"All changes as of 18th Sept"

How tremendously useful? There I was looking to know what changes were made to enable a feature / service, thought I could look for that in the commit message, but no you've given me a much more efficient way of finding out.

I simply need to download the contents of your memory, find out what date you made a change, and then dig through the massive commit to find the piece of info I need.

Forget experience using Git features, managing merges, following Git flow, or even any other SCM ... how can people be so tick when it comes to recording what they've done.

Heres a little cheat sheet for those struggling:

- Commit message
Describe what you actually ****ing did. Don't tell me the date or the time, thankfully Git records those. Don't tell me the day of the week, if I need to know I can figure that out, just tell me what ... you ... did.

- Feature branch names
Now this is a tricky one. You might be surprised to know that this isn't in fact suppose to be whatever random adjective or noun popped into your head ... I know, I too was shocked. The purpose of this is to let other people know what new feature is being worked on in this branch.

- Reusing feature branches
Now I know you started it to add some unit tests, and naming it "testing" is sort of ok. But its actually not ok to name it testing when you add 3 unit tests ... then rip out and replace 60% of the business logic. Perhaps it would have been wiser to create a new feature branch, given you are now working on a new feature.

delete unused code according to IDE

unit with context tests now fail

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

My status update for tomorrow:
"I've done the tests and have the results, now all I have to do is work out what the numbers mean coz I started this task 6 months ago and have spent most of the last 6 months putting out fires elsewhere and have no idea what I was doing".

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

My Precalculus teacher has such overstrict rules on showing work.

1. On tests, degree signs must be shown in all work. This wouldn't be outrageous except that if the answer is right but a single degree sign is missing in the mandated shown work, the entire question is wrong even with a correct final answer because the "answer doesn't match up with the work".

2. We must show work in the exact form mandated from on class. If even a single step of work is missing or wrong on even one say homework problem, no credit even if the entire rest of the sheet is correct and complete.

3. Never applied to me, but if a homework problem cannot be solved by a student, they must write a sentence describing how far they got and what wasn't doable, or no credit on the entire homework. Did I mention it is checked daily and is 2 unweighted points with 50-100 point tests?

4. On graphing calculator problems, one had to draw a rectangle representing the calculator screen, even for solving systems of equations without explicit drawing graphs as part of the problem, because otherwise, she had "no proof that a calculator was used". It isn't that hard to fake, and it was quite stupid.

5. Reference triangles were required even when completely unnecessary or the answers were assumed copied, even if a better method was shown in work.

And much, much more!

We are not ready, I won't sign on this shit I said!

Release on Friday, what could go wrong? All unit tests passed they said!

It's Tuesday and shit is still broken!

FML

PSA: negate your tests and make sure they fail!

I have what I thought was a weird and slightly paranoid habit. When I write tests sometimes just as a sanity check negate the assertion to make sure the test fails and isn't a false positive. Almost always fails as expected.

But not today! Turns out I had forgotten to wrap my equality check in an assertion so it would always pass. It freaks me out to imagine pushing a test that always passes not just because it doesn't do its job, but could also obscure a bug and trick me into thinking it works differently than it does. Broken tests are the worst!

But it pays to be paranoid.

I'm facing big issues on one of my apps and luckily a user is helping me doing some tests as I can't reproduce the issue. He just sent me an email and guess what?! He wrote "happy weekend". No. It's not going to be an happy weekend for me.

Have you ever installed libc++?

If you haven't then i warn you.
When libc++ installs it does a lot of tests and it takes fucking forever!
What the fuck!
What are you even testing? How long patience people have?

And sorry for not screenshoting. I dont want to accidently interupt their "testing"

Note to self: Pointing your tests at a non disposable DB will cause very very bad things to happen. No idea what the flying fuck I was thinking - but praise to the data gods it wasn't a production elastic!

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.

I have some phone interviews coming up next week but I've never had these before. Usually I do online tests, shared code, or in person as I'm deaf.

This time I just want to try using a voice relay, so v basically whatever the person says it's transcribed... So wondering what do you actually talk about in these "quick calls"?

Party of the reason I don't like phone is because there are a lot of technical terms which will probably screw it up... But just wanted to give it a try and not 100% interested this time...

Was intending to, applied, then other things came up so now not so sure, some came back so just gonna wing it for the experience I guess

I've lost hope in my precision at this point:

We've updated our website to have X feature. The X feature was implemented, tested and even had unit tests... The worst part when I've lost hope? Both unit and the actual code had the same mistake in them. What was the mistake? Well...

if($variable = 'something') {}

Yeah... Read it carefully... We've always had the same case and only noticed it after 3 months when it was attempted to extend.

Funny enough, few users were harmed but no actual reports of an issue came to us.

Since then, I'm always triple checking that I have the correct amount of `=` to avoid further fuck-ups

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

When a bunch of unit tests start failing locally because the AWS secret key got rotated.
oh wait...
THOSE AREN’T UNIT TESTS!!!
Unit tests do not depend on any external system, that includes AWS...
AAARRGHHHHH

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.

We use a third party paid company to produce a service and give ongoing support for it, which all our revenue streams depend upon. They are shit and their service is shit. Here's how my conversation about testing went today.

Me: 'hey X wrote an integration test project for the service. It shows the service is broken 50% of the time. We should give their team access to it and have them run it as part of CI'

Colleague: 'They are too shit to setup CI'

PM: 'we are stuck with them so there is no point. It is what it is'

Boss: just ignores me. Not even a reply.

Some days later

Head of QA: 'Hey Dev and QA are broken'

Me: 'because their service is broken. I made so and so suggestion before but it was rejected. We will just have to accept Dev and QA are broken 50% of the time'

Head of QA: 'no we cant'

Me: 'ok so we should setup the tests to run by giving them access'

Head of QA: 'No we shouldn't. The tests can only be used by us and if they break it tells us so we can act on it, or choose not to'

Me: 'We would not want to act immediately on all our revenue streams breaking? Yes we can reverse engineer their client and fix errors as they occur, or we could just have them run the tests and a team our company pays for can stop adding breaking changes to their own API every other day. Right now it has been broken for 2 weeks.'

Head of QA: 'in an ideal world we would have an internal team so you're wrong'

Me: :)

I really don't understand how they can come to such a conclusion. Am I missing something or am I surrounded by total fucking idiots?

"I don't see the point of writing tests on this project. It's just a waste of time. "

3 months later:

"I don't know what's broken and every time I change something I don't know what it could possibly break?"

FFS.

I'm unmotivated and tired today. I'm just running tests in different branches to see what bug I can find... and since the testing take 5 minutes to complete, I just watch videos in between...

Making calls, meetings, and "brainstorming" half-baked features or designs or any other slop bullshit for 12 hours a day?

Wow, you are an impressive "startup bro"!!!

Coding, testing, running emulators, tests, reading technical documentation, ensuring product success in the real world, and implementing efficient full stack software for 12 hours a day?

Fuck you!!!

These are the expectations of management. Just remember, what they do is "extremely difficult", but you are simply just a resource queue that takes input and converts it to real-world implementation.

Give me a fucking break

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

I'm genuinely shocked at the number of people I see on here bashing automated testing as a waste of time, simply because my entire career has taught me the opposite (and it's usually only non-technical managers I see who don't want to see "time wasted" writing tests.)

I'm also just as genuinely curious - what do you guys do instead? Just don't test and deal with production issues as they occur? Pass it off to a separate UAT / human-based testing department and let them sign it off? Assume that because you're using Haskell / some other discipline it'll work if it compiles?

What do we say to writing unit tests?

Not today.

Cocktail for disaster:

- TDD
- Mocking
- Multithreading
- Averagely well written, testable code
- All tests pass
- One test methods still shows some vague stacktrace in a worker thread ❌ but the test passes ✅
- Run only that test method and no stacktrace.

So I've been pulling my hair for the last two days trying to figure out what was throwing in that test method. Turns out that thanks to the multithreading going on, some other, similar method threw the exception in parallel. And apparently a different test method was already running when the exception was finally caught.

🖕

When I discovered that, it was fixed in a minute. 😭

?rant
We bought an expensive middleware which helped development speed and stability a lot. Something did not work and after a week I located the bug in the middleware. Support was adequate and the bug got fixed after my report.
I'm not mad at the developers, because bugs happen, and this one was hard to catch, even with tests.
On the other hand I have to explain my boss what took so much time.
It really wasn't my fault, but I also don't want to shame the middleware company, because it will make it harder for me to buy their stuff (and I quite like their products) or even any software at all.

Real men push to master and test in prod.

It's been broken in production for two weeks, and you want to tell me it's "drop everything urgent" now? Is it important? Yes. Is it urgent? No.

Also, how the fuck did you not know this was broken for two weeks, and what the hell do you want me to do about it now? It's your codebase, it passed all the tests in staging AFTER I made my changes to the infrastructure.

Yeah so I quickly hacked stuff together. Why make it beautiful before I know whether it will actually do? Hack now, refactor later!

Yeah and then that moment in refactoring where main() gets under 700 lines and I don't know whether what I'm feeling is joy or despair. Gaaaahhhh!

At least I have also written automatic tests so that I can see when something breaks.

Things I love today.

Totally love. Like kick in the balls with testicle torsion love. Picking my eyeballs out with a spoon... I think you got the idea.

Getting updates of other managers, as I'm busy with other stuff.

More or less goes like this:

Flaky tests. Since weeks...
Ain't nobody got time for that.
🤬

I don't wanna upgrade that version to the next major version, cause then I'd have to do tests... And the tests are flaky.

🤬🤬

I wanna have shiny new thing XY, but NOONE wants to upgrade to next major version so we cannot have that

🤬🤬🤬

Oh we just crushed the live cluster cause there's this PR everyone constantly ignores cause the tests are flaky....

🤬🤬🤬🤬🤬🤬🤬🤬🤬🤬🤬🤬🤬🤬🤬🤬🤬🤬🤬🤬🤬🤬🤬🤬🤬🤬🤬🤬

Good thing I'm busy and just getting all the updates via the gossip mill...

I'm just prolonging my current tasks as I really don't wanna have to fix that mess.

My fix would be probably eye for eye, tooth for tooth.

...

Problem is.... I'm slowly getting into trouble because some of these fixes would be much needed for my task...

Why do I have always to be the bad cop in the company -.

I think I'm gonna ask HR what applying electro shocks would cost me, cause I think that would solve a lot of problems.

10 kV for every stupid answer.

Smells like bacon!

I've been working on this fucking instagram connector for 4 weeks now, mainly due to idiotic red tape

Now the time has come to get it approved. I'm supposed to let them know how to test the connector with a test user. but FUCKING facebook's test users don't even work as test users! their own spam catcher identifies their own test users as bots!!!!

I mean what the fuck!!!! HOW AM I SUPPOSED TO GET THIS APPROVED IF YOUR TEST USERS DON'T FUCKING WORK AS PART OF THE TESTS

AAAAAAAAAAAAA THIS IS FUCKING INFURIATING

In the 90s most people had touched grass, but few touched a computer.

In the 2090s most people will have touched a computer, but not grass.

But at least we'll have fully sentient dildos armed with laser guns to mildly stimulate our mandatory attached cyber-clits, or alternatively annihilate thought criminals.

In other news my prime generator has exhaustively been checked against, all primes from 5 to 1 million. I used miller-rabin with k=40 to confirm the results.

The set the generator creates is the join of the quasi-lucas carmichael numbers, the carmichael numbers, and the primes. So after I generated a number I just had to treat those numbers as 'pollutants' and filter them out, which was dead simple.

Whats left after filtering, is strictly the primes.

I also tested it randomly on 50-55 bit primes, and it always returned true, but that range hasn't been fully tested so far because it takes 9-12 seconds per number at that point.

I was expecting maybe a few failures by my generator. So what I did was I wrote a function, genMillerTest(), and all it does is take some number n, returns the next prime after it (using my functions nextPrime() and isPrime()), and then tests it against miller-rabin. If miller returns false, then I add the result to a list. And then I check *those* results by hand (because miller can occasionally return false positives, though I'm not familiar enough with the math to know how often).

Well, imagine my surprise when I had zero false positives.

Which means either my code is generating the same exact set as miller (under some very large value of n), or the chance of miller (at k=40 tests) returning a false positive is vanishingly small.

My next steps should be to parallelize the checking process, and set up my other desktop to run those tests continuously.
Concurrently I should work on figuring out why my slowest primality tests (theres six of them, though I think I can eliminate two) are so slow and if I can better estimate or derive a pattern that allows faster results by better initialization of the variables used by these tests.

I already wrote some cases to output which tests most frequently succeeded (if any of them pass, then the number isn't prime), and therefore could cut short the primality test of a number. I rewrote the function to put those tests in order from most likely to least likely.

I'm also thinking that there may be some clues for faster computation in other bases, or perhaps in binary, or inspecting the patterns of values in the natural logs of non-primes versus primes. Or even looking into the *execution* time of numbers that successfully pass as prime versus ones that don't. Theres a bevy of possible approaches.

The entire process for the first 1_000_000 numbers, ran 1621.28 seconds, or just shy of a tenth of a second per test but I'm sure thats biased toward the head of the list.

If theres any other approach or ideas I may be overlooking, I wouldn't know where to begin.

The feature was to parse a set of fairly complex xml files following a legacy schema. Problem was, the way this was done previously did not conform to the schema so it was a guideline at best, which over the course of many years snowballed into an anarchy where clients would send in whatever and it was continuously updated per case as needed. They wanted to start enforcing their new schema while phasing out the old method.

The good news is that parsing and serialization is very testable, so I rounded up what I could find of example files and got to work. Around the same time I asked our client if they had any more examples of typical cases we need to deal with, and sure enough a couple of days later I receive a zip with hundreds of files. They also point out that I should just disregard the entire old set since they decided to outright cut support for it after all if it makes things simpler. Nice.

I finish the feature in a decent amount of time. All my local tests pass, and the CD tests pass when I push my branches. Once we push to our QA env though and the integration tests run, we get a pass rate of less than 10%.

I spend a couple of days trying to figure out what's going on, and eventually narrow it down to some wires being crossed with the new vs. old xml formats. I'm at a loss. I keep trying to chip away at it until I'm left with a minimal example, and I have one of those lean-back moments where you're just "I don't get it". My tests pass locally, but in the QA environment they fail on the same files.

We're now 3 people around my workstation including the system architect, and I'm demonstrating to the others how baffling and black magic this is. I postulate that maybe something is cached in my local environment and it's not actually testing the new files. I even deleted the old ones.

"Are you sure you deleted the right files?"

"Duh of course -- but let me check..."

Holy. Shit. Tests. I am testing. All week. Nothing but tests. I am one with the spec. You know what I realised today? Tests are a bit like life. Life is just one big spec suite that takes 75 years to run. Except there's no prod environment at the end of the DMT tunnel waiting for our green pass docket to say 'take me Lucifer, you absolute visionary: I'm ready'. We're all just a spec with no application. We're doomed. Nothing matters. I need to lie down

Okay, wait, is it a common practice to push changes to master that you KNOW break some other features? I always assumed that that's what branches are for and master should be the "to the best of our knowledge it should be production ready"? But apparently in this company you need to hunt for the right revision, interrogating people why suddenly nothing works on your end and half the time it's "oh, this guy has been working on something and it broke half of the stuff others have been working on and isn't covered in tests yet. Use revision 21xkcd7a"

A friend of mine is youtuber and he does a lot tests on phone ( call him X)
Another friend of mine hates Apple product. Partly because he can’t afford it (call him Y)

whenever X wants to do a WATER RESISTANCE TEST, Y would go: “Lets fuck Iphone”
whenever X wants to do a HEAT RESISTANCE TEST, Y would go: “Lets fuck Iphone”
whenever X wants to do a DROP TEST, Y would go: “Lets fuck Iphone”

One fine day, same happened and X got a bit red. X says: Y come here. Closer, a little more ( few centimeters away now). “Are you fucking mad or what?”

I did one of those shitty logic bullshit tests these a few weeks ago. It was fucking dumb. Was told to write an algorithm to test when an egg would break if it was dropped off a ladder with 100 steps. An egg would break if you dropped it without being on a ladder. Am I right? The guy was like yeah but what if it didn't? I said Well it would. Eggs are fragile. How about you go away with your fictional fucking logic and ask me some proper question that test my actual coding knowledge instead of trying to pony about on your high horse. Cunt!

The build breaks due to a failing unit tests, and what does the dev do?

Comment them out.
Commit.

Our favorite ticket system blokes are back with a big fat update for their software.

What changed?
All workflows are fucked because everything is somewhere else suddenly!

Half of the features suddenly stopped working!

Variable formats in forms have been changed from {} to [] without reason, migration or warning! Sorry, {Username} ¯\_(ツ)_/¯

Half-assed features that don't work half of the time have also been added!

Fucking great!

Who beta tests this shit? Nobody?

My old boss who somehow has gotten his small team of 4 PHP development contracts with Vodafone and Tesco etc. No QA, no tests, no frameworks allowed.

Sets random deadlines and used to suddenly drop demos on me for projects I'd just started and he had no idea of the state of them. Needless to say one project I was so rushed with no idea what I was actually making (for real) that I got sacked.

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!

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

Developed a feature 4 weeks ago with a lot of requirements from PO, even more from QA, wrote beautiful code/tests, was actually happy after deploy since everything worked beautifully.
Sales increased a lot because of this.

Story created in Jira today by mentioned PO: As a PO I want to have that feature removed because it doesn‘t work in IE9. PO decides so I had to do this.

So: What exactly is the best way to hide a body?

I'm very sad. I had to do 5 challenges in Hackerrank for a job and I managed to complete only 1 in the allotted time.
What makes me sadder is that in one challenge, the testing the compiler did was different than the challenge description (getting me failed tests).
Damned job hunting, I'm losing hope with each passing day... 🙁

Stop commenting out code blocks!

Either fix your shit or delete it.

I am open to argue what fixing may mean, as it is perfectly fine to make your broken code not reachable, e.g. via feature flags or skipping certain tests. Yet never ever should you comment those blocks!

So you say you want to keep it for historic reasons? You know, that is why we use version control! If you ever need certain functionality back, you can restore that state.

Each decent IDE also offers a local history where you can even restore code blocks that weren't even pushed or committed. So use that!

Commenting out test cases is a really bad habit, as you have no reminder that you shall restore it.

And no, a TODO and a FIXME won't count as a reminder as you have to actively look for them. And we all know how well that goes, don't we? (One time, I found a typo of a `TDO`. So even with a regular lookup for TODO, stuff will slip.)

Each test suite offers you ways to skip tests if there are valid reasons why they should not fail the build temporary and they offer colorful feedback. Yes, that means that your tests won't be green, but guess what: That's a feature! They shouldn't be.

That yellow is a fine reminder, aka warning!, that you should really fix your shit.

Commented code screams: "I DON'T KNOW WHAT I WAS DOING!" and it confuses the hell out of other developers ("Was this commented because of debugging purposes and should be active again or can I safely delete this!?") and adds verbose crap to the code base.

If you find yourself to be in a place that you comment code a lot, I also argue that your workflow is broken.

When you are using a decent debugger, there shouldn't that much of a need to comment in and out a lot of code in order to reason about your code-base.

Hi guys!

Hopefully going to be heading to a job interview as a Junior Front End Developer over the next few weeks. Primarily a web designer but taught myself to code as well. The job uses HTML, CSS, JavaScript and Angular. I've heard a few people mention tests companies use in interviews, has anyone had any experience with these? What type of things should I prepare for?

Anyone else like... REALLY bad at algorithms and logic stuff?

I just hate them so much.

Tell me to build something and gg done. But all these tests for jobs freak me out.

Like. It probably ends up being something simple and when it's explained I know what to do but at first I just instantly shut down and can't think.

I'm in this university software engineering course, where the professor decides he need to teach us the entire history of software engineering.

Dude, we were taught how to use SVN in addition to Git. Huh? And for software development processes, we were taught a total of 7 of them. There're: code and fix, waterfall, prototyping, spiral, phased, agile and lean. And the tests are like "list 5 advantages and disadvantages for X, and compare them to the advantages and disadvantages of Y". Wtf dude. I don't mind memorizing things, but the things I learn aren't even relevant (except agile and lean). Nobody would be impressed if I say I know SVN in an interview. What am I doing with my life. Ok, back to cramming this shit cuz i need my GPA. Bye.

If I'm writing an app which has the sole purpose of receiving some data from a server, then sending some other data back (so nothing is stored locally) - what sort of stuff do I write tests for?

Client wants lots of testing to occur, but all of the tests I can think of wouldn't add any value

Actually, it happened just before my current holidays.
I had prepared a whole system to feed and use a machine learning model. My colleague and some others had been working on a great thing, all encapsulated, all abstracted for my system.
My last day at the office, they had it ready.
I install their thing, load one model and launch one dummy prediction: error. I try with other input data: error
I try debugging a bit more, errors all the way. Knowing them, I asked if they wrote some unit tests.
"Sure we did"
I find the tests, yes there are some. And I notice:
"Hey, I see that in all your tests, you're making more than one prediction at a time (=aka using a matrix with more than one row)
- yeah, and it work fine
- in the project, we're doing one prediction at a time, did you try it with one prediction?"
He tries: error, that was totally what I said.
I started ranting on loosing the scope of the project, why we do tests in the first place.
Then, I grabbed my coat, said "see you in one week" and let them rework their code.
I was so angry at them, it seemed so basic to just check that 👹

Me: What if I use navigation props in EF Core, what might go wrong?

*tests API call*
*120 seconds later finally got result*

Me: I better undo my changes and stick with 2 seconds response time O_O

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

I tried to apply to TrippleByte just to see if I could get a job through them...
Their tests are soo hard imo
It's not like I lack skills in programming its just that they require you to have a VERY varied background and only give you about a min to answer each question which can take a slow code reader that long to read without having even processed what the answer may be ;u;

This isn't making me feel good about my white boarding skills since I have yet to be in one of those. I'mma need all the help I can get @_@

Linux users:

What was your distro journey?

Mine is composed of the following time-based list of the primary distros I've used, along with a smattering of flash-in-the-pan tests, including but not limited to Suse, OpenSuse, OEL, CentOS, Sorceror, Vector, Mint, and ElementaryOS.

1998-1999: Redhat 5.1, 5.2, and 5.3
1999-2002: Debian
2002-2005: Gentoo
2005-2007: Debian(I still use it for cloud VPSes)
2007-2019: Ubuntu
2019: Manjaro
2019-Present: Arch

Any professional pentesters or someone working in cybersecurity as a profession? I need some advice. The company I intern with right now wants me to test their web applications for security (they really don't care so much about security). I just wanted to know is there a standard set of procedures or a checklist that is usually followed? I know automated testing is not all that effective against web applications but what are the steps you usually take?
As of now, I have run tests and am now performing a code review but it's in PHP and I'm not really good with it. I'd like to know what more is done as a standard please.

Finally made my node production server stable enough that I could focus on writing tests*. I start by setting up docker, mocking cognito, preparing the database and everything. Reading up on Node test suites and following a short tut to set up my first unit test. Didn't go smoothly, but it's local and there are no deadlines so who cares. 4 days later, first assert.equal(1+1, 2) passes and I'm happy.

I start writing all sorts of tests, installing everything required into "devDependancies," and getting the joy of having some tests pass on first try with all asserts set up, feels good!

I decide to make a small update to production, so I add a test, run and see it fail, implement the feature, re-run and, it passes!

I push the feature to develop, test it, and it works as intended. Merge that to master and subsequently to one of my ec2 production servers**, and lo and behold, production server is on a bootloop claiming it "Cannot find module `graphql`". But how? I didn't change any production dependencies, and my package lock json is committed so wth?

I google the issue, but can't find anything relevant. The only thing that I could guess was that some dependencies (including graphql) were referenced*** in both, prod and dev, and were omitted when installed on a prod NODE_ENV, but googling that specific issue yielded no results, and I would have thought npm would be clever enough to see that and would always install those dependencies (spoiler: it didn't for me).

With reduced production capacity (having one server down) I decided to npm uninstall all dev dependencies anyway and see what happens. Aaaaand it works.....

So now I have a working production server, but broken local tests, and I'm not sure why npm is behaving like this...

* Yes I see the irony.
** No staging because $$$, also this is a personal project.
*** I am not directly referencing the same thing twice, it's probably a subdependency somewhere.

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

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

It's only August but I already know what I'll be thankful for come Thanksgiving:
1. Our next president.
2. Integration tests.

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*

So our Chief Test Engineer left the company because of overwhelming frustration and stress. We working on new stuffs so we test our partly done product with partly done test tool developed be another of our team. His successor started to drop most of the 3rd party tools and workflows and documentations to trash expect this one unfinished test software.
Now he wants that we add more features to this software so it can replace everything he trashed already: run tests, generate test reports, generate documentations and so on.
On top of that he organized a workshop to read all this software's source code together, understand how it's works so we can rewrite the whole software from scratch.
WHAT?!

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

I’m curious what works for you? Lyrics or instrumental music while you’re working? I find myself preferring instrumental music while I’m thinking about a problem. The music can be technical and busy or super chill, but lyrics always distract me.

Of course, If I’m just half focused and grinding out mock responders for my unit tests then lyrics are fine.