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

Wordpress does not suck. If you know how to work it.

Past period I saw so many rants on WP. My rant is that it is not 100% WP fault. Yes there are seriously structural problems in WP but that does not mean you cannot create top-notch websites.

At my work we create those top-notch WP sites. Blazing fast and manageable. Seriously we got a customer request to make the site slower because it loaded pages to fast (ea; you hardly could see you switched pages).

- We ONLY use a strict set of plugins that we think are stable, useful.
- We have everything in composer (and our own Satis) for plugins.
- We use custom themes & classes. Our code is MVC with Twig.
- In our track history we have 0 hacked websites for the past 2 years.
- Everything runs stable 24/7
- We have OTAP (testing, acceptance & production environments)
- We patch really fast

These are sites going from $15k++ and we know our shit.

Don't hate on WP if you have no clue what you are doing yourself.

That is my rant.

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

These postings on angel.co

I swear to God it's like I've uncovered a conspiracy theory.

I had been searching for a side project now that holidays are coming and I really don't wanna get bored.

Applied to a few companies. About 5 of them "responded" with an acceptance. I write them my interview timings and all that's required.

Nothing. Nothing for like a solid week and a half.

Meanwhile I applied to more companies and still the same thing.

I decided to manually mail their companies regarding the process, so that I can, preferably, move on to other ones if they have rejected the application (which they obviously hadn't)

I get mails from almost all the companies with some or the other variant of "We were waiting for your reply to proceed"

I tell them I had replied over the conversations and they said they never got a message.

Now feeling that this might be angel.co at fault. I wrote a request to look into the issue. Meanwhile I tested the system using a friend's account as a recruiter and testing myself.

Unsurprisingly it was working flawlessly.

Narrowing it down to the companies then.

I sent a document with my findings to each of the companies and pretty much 50% of them stopped with replying.

The rest confirmed that they hadn't received any mails regarding the same and they saw no mail resembling the one I tested with my friend.

Kinda confusing but I asked them to look into it.

Meanwhile mail from Angel returns saying that their system is working perfectly fine even around my region. So idk what was the problem

I got a mail 3 weeks after the first mail to the company. They had been using a utility to auto-accept/reject profile applications. This util sent a lot of mails, even for rejections, to their mailboxes, filling them.

So they decided to remove these emails automatically by marking them spam. Apparently, the interview confirmation messages also count as these emails and were automatically archived. Thus removing my responses to those companies.

Idk if this is widespread issue because only one company has responded to me yet.

I'm still livid with this shit.

Gotta love product owners that don't seem to understand agile.

We delivered the set number of items in the sprint we committed to plus a little extra polish. During the last day of the sprint we're spending the time to push all our work to UAT do he can actually perform acceptance testing...

He decides he should chase all of us up on stuff that we never commited to or even mentioned we'd touch.

Had to explain it to him at least 5 times during the day.

> Client complains acceptance testing is too expensive and that he'll do it himself.
> Client complains acceptance testing wasn't thorough enough when a bug hits production.

Holy crap, I can't take it anymore.
I know that user acceptance testing is supposed to be done by the end user but it's as if they entirely skipped UNIT TESTING and QUALITY ENGINEERING.
Does their API work? Yes. It does.
Are their endpoints working? Sort of... why are query parameters required again?
Is it good overall? No, there are CORNER CASES ALL OVER THE PLACE (are they even still corner cases at this point?). It feels like it was made by amateurs!
Why am I doing quality testing on their services??? holy crap, they should pay ME for doing this

Jesus fuckin' Christ. I own a webshop together with someone else. This guy is so fuckin' stupid. Yesterday I've deployed a release to our acceptance environment. I talked with him extensively about it. This morning I texted him to check out all the new stuff.

5 minutes later he texts.me back: I would suggest changing option x. Uuh... what option x? We don't have that any more.

Dude! What the fuck! We talked extensively about acceptance testing so you know it is in our acceptance environment, not production, asshole.

And then again, he asks for the link to the acceptance, which I gave him twice already.

Are you really that stupid??

I've been interested in security for years but despite knowing the theory I've always had this disconnect with actually doing it, about two years ago I finally managed to find and exploit my first cross-site scripting vulnerability in my companies Product whilst doing some routine acceptance testing. It was a penny drop moment for me which has led to some very interesting projects and It was pretty badass.

I'm supposed to find why a pdf is not generated correctly. But here is the problem :

I don't have access to the production to see the bug and the pdf they gave me is different to the ones I generated myself. But ! It's not over :
My local version does not generate the same pdf as the acceptance testing version !

So here I am, with three different pdf and only the possibility to modify the local one, where the bug isn't.

Today is day two of User Acceptance Testing for one of our biggest and most complicated developments.

Today is also the day the requirements were agreed.

Somebody, somewhere is taking the piss.

Ya know, automated testing was supposed to save me time and trouble... Seems like it's just a different place for bugs to crop up

In every single group project at my university, there is always that one guy that doesn't do shit:

Last year, we were a group of four students developing a website. One guy had never seen HTML before and was just filling the website with lorem ipsum and break-tags. One student didn't work a lot on the project, but developed a few bugs. The last guy, did not even spend 1 second working on the project.

A few days remaining before the projects deadline, and all we had left was to write a report on how we did acceptance testing. I was sure he would not get the same grade as the rest of us since I emailed the course coordinator, saying that this guy hadn't been contributing with shit.

However, just before the deadline, this guy starts making massive amounts of commits to the repo were he changed like one single character in our report, or just edited single words. The course coordinator probably just checked to see that everyone had committed to the repo, because everyone got the same grades!

My code is in Acceptance Testing phase, and I got a defect reported.

I tried to redo the same without changing the code, it works for me

god dammit

Can anyone suggest any websites or resources for a breakdown of how to handle requests for features or handling bugs. Basically, I want some kind of background on best practices for managing the process of receiving a feature request/or bug report from a user to it reaching the dev team, to production/user acceptance testing.

Vague requirement for feature A received from client
Business consultant refines
Example mapping done
Acceptance criteria defined
Scheduled in sprint
Development done
Unit tests passed
Pull request reviewed
Code merged and deployed to system test
Functional testing successful
Deployed to UAT
Client asked to sign off

Client: "Actually I don't want that feature."

Just spent 3 hours on a bs problem

I just start acceptance testing a node.js api.

I'm using frisby

I have logged the export method return data and it is correct

I am loading it into the set header function as the accept-type

On frisby side I run the test and it spits out that there is no accept-type

I really don't get why anymore. Came so close to a blind fury.

One of our dev team had the task to do a bulk operation for thousands of objects.
So time passes by and they implemented it. But in acceptance testing they found out that this operation takes 4 minutes for 50 objects. This is not what we call high performant when we talk about 20000 objects per bulk operation 🤔

Well, their PO asked them to solve that performance issue. And guess what, they decided on their own that the issue can be solved to reduce the bulk to 20 items so that it only takes 2 mins to run!

Really guys, is that the best you can come up with?! 😲🤬

Only when the latest feature is implemented, the last bugfix and the last workaround are found, the last unit test is written, the latest CI/CD pipeline done, the customer guy does manual testing and acceptance tests on the staging server and let's them pass and a few days later it's pushed to production...
You will be reminded (again) that shitty customers do exist! A customer is the least capable person to tell you what the customer actually wants and is also the least trustworthy person to test the features he requested...
Holy fuck come on! Just test that shit on the staging Server! One Look could have already shown you that that's Not what you expected!

I checked the logs after that and yup you guessed correctly... The said endpoints weren't even used on staging, only on production...

When I'm in a bad mood I think about people that have to do acceptance testings

Robert Martin says in clean code, or maybe clean architecture, that one should separate the tests into what is hard and easy. GUI tests are hard and therefore brittle and so we should test against view models.

However on clean agile he says a story is not done until it passes automated acceptance tests which in my experience are always brittle and grow so large and brittle that things grind to a halt.

What am I missing? Are stable acceptance tests possible on the GUI? Should we test only an API?

!Rant
Upgraded laptop RAM from 2gigs to 6 gigs. Was never so happy. Numerous browser tabs. Two three node apps. Slack. Acceptance testing using Codeceptjs. All With delay. Ah bliss.