Been lurking here for a while. Finally pissed off enough to post.

Been programming in Ada for nearly a decade now. One of the few younger devs who knows the language well. Have a large collection of libraries and tools written in it, open source. Done contract work. Looking to get out of my current line of work, which is medicine, because fuck this recent legal climate. I'm spending all my time dealing with legal compliance and it rapidly changing.

I see a job posting from a company looking for a programmer to mostly write testing stuff for clients. They mostly work with Ada. I've written a whole unit testing and integration testing framework. Perfect. Apply. "You don't have the required skills." Oh... K then.

Wanna guess what I was just offered as contract work. Same company. I guess i'm fucking qualified if you asswipes sought me out to ask me to fix your fucking bullshit.

What the hell is wrong with management and HR in recent years?

Two unit test suites. No integration testing.

We tested each and every setter and getter, what can go wrong with integration?

!rant
!!git

Who here uses `master` for development?

My boss (api guy) tried to convince me that was normal practice. I gently told him that it sounded crazy and very very bad.

Here's the dev path I'm enforcing on my repos:

(feature branches) -> dev -> qa* -> master -> production*

*: the build server auto-pulls from these branches, and pushes any passing builds to staging/production.

Everyone works on their own feature branches, and when they're happy with their work, they merge it into `dev`. `dev`, therefore, is for feature integration testing. After everything is working well on `dev`, it gets merged into `qa` for the testers to fawn over and beat with sticks. Anything that passes QA gets merged into `master`, where it sits until we're ready to release it. When that time comes (it's usually right away, but not always), `master` gets merged into `production`.

This way, `master` is always stable and contains the newest code, so it's perfect for forking/etc. Is this standard practice, or should I be doing something different?

Also, api guy encourages something he calls "running a racetrack" -- each dev has their own branch (their initials) and they push to that throughout the day. everyone else pulls from it regularly and pushes to their own branch. When anyone's happy with their code, they push from their (updated) branch to `qa` (I insisted on `dev` instead.)

Supposedly this drastically reduces the number of merge conflicts when pushing to an upstream branch due to having a more recent ancestor node?

I don't quite follow that, but it seems to me that merging/pushing throughout the day would just make them happen sooner? idk.

What are your thoughts?

!rant but a story

This happened today. Sorry for long post. A manager from another team in development team, I'll call him junkfellow, called me very very late last night to help them solve an issue in our application's test environment that blocking them from doing testing. They apparently doing integration testing with our application. Now said test environment is not even prepared by our team. We are development team and this test environment prepared by our application's support team. So I politely told junkfellow to get in touch with our support team counterpart as I am from development team. And he began shout at me

junkfellow: "WHY DO YOU THINK I'M FUCKING CALL YOU? IT'S BECAUSE I CAN'T FUCKING REACH ANYONE FROM SUPPORT!"
me: "With due respects sir I have no instructions to assist you and your team in your testing"
junkfellow: "THEN WHAT GOOD ARE YOU? IF YOU DON"T GET ONLINE NOW I WILL FUCKING ESCALATE YOU TO CW!!!"

We all know who CW is and he can make some people life very hard and I didn't want to call my boss so late so I quickly went online and spent the next 4hrs supporting their testing. Next morning I told my boss what happened and he scolded me for not calling him last night. He dropped an email to junkfellow's boss about junkfellow being "unacceptable attitude, disrespectful and threatening to escalate my team mates". My boss always refer to us as team mates, not his staff or his team member.

Then in few minutes, someone walking like a school bully with his chest out came to my boss place and announced himself (he is junkfellow). I say announce because he talking like he wanted everyone to know who is he. My boss stood up promptly, greeted good morning, introduce himself, shook junkfellow hand and sat down. Still young, maybe in late 20's or even younger than me. junkfellow talking to my boss loud enough for most of us to hear. Everyone's neck suddenly long like meerkat and listening:

junkfellow looking down to my boss who is sitting down: "How dare you send email like that to my boss? We are both managers you should act like one, you have a problem with me then you talk to me. You don't bypass me and go directly to my boss. You didn't even give me face!"
my boss sitting down: "So you didn't even ask your boss before picking a fight."

*junkfellow suddenly look confused*

my boss still sitting down talking calm with poker face: "I did give you face. You think by going to your boss I bypassed you and went one level up? No I went one level down!"

junkfellow still look confused and then slowly realized what my boss meant. Now he is staring at floor and can't look my boss in eye after he realized he is screwed!

my boss now standing up: "You treat my team mates like that againi or ask them to do something without my knowledge and I will talk to your boss' boss about it"
boss to me: "Hey tollywood! junkfellow here sincerely regrets what he did last night and wants to apologize to you in person" and boss' poker face turned to his familiar smirk

junkfellow immediately came to me, said "it's ok you no need to stand up", he sat down in a squat and apologized repeatedly. He really looked like he was about to cry and for a moment I pity him. But then I remember what he did and I just enjoyed the moment! Was pure gold :D :D :D

Imagine if a structural engineer whose bridge has collapsed and killed several people calls it a feature.

Imagine if that structural engineer made a mistake in the tensile strength of this or that type of bolt and shoved it under the rug as "won't fix".

Imagine that it's you who's relying on that bridge to commute every day. Would you use it, knowing that its QA might not have been very rigorous and could fail at any point in time?

Seriously, you developers have all kinds of fancy stuff like Continuous Integration, Agile development, pipelines, unit testing and some more buzzwords. So why is it that the bridges don't collapse, yet new critical security vulnerabilities caused by bad design, unfixed bugs etc appear every day?

Your actions have consequences. Maybe not for yourself but likely it will have on someone else who's relying on your software. And good QA instead of that whole stupid "move fast and break things" is imperative.

Software developers call themselves the same engineers as the structural engineer and the electrical engineer whose mistakes can kill people. I can't help but be utterly disappointed with the status quo in software development. Don't you carry the title of the engineer with pride? The pride that comes from the responsibility that your application creates?

I wish I'd taken the blue pill. I didn't want to know that software "engineering" was this bad, this insanity-inducing.

But more than anything, it surprises me that the world that relies so much on software hasn't collapsed in some incredible way yet, despite the quality of what's driving it.

Worst dev team failure I've experienced?

One of several.

Around 2012, a team of devs were tasked to convert a ASPX service to WCF that had one responsibility, returning product data (description, price, availability, etc...simple stuff)
No complex searching, just pass the ID, you get the response.

I was the original developer of the ASPX service, which API was an XML request and returned an XML response. The 'powers-that-be' decided anything XML was evil and had to be purged from the planet. If this thought bubble popped up over your head "Wait a sec...doesn't WCF transmit everything via SOAP, which is XML?", yes, but in their minds SOAP wasn't XML. That's not the worst WTF of this story.

The team, 3 developers, 2 DBAs, network administrators, several web developers, worked on the conversion for about 9 months using the Waterfall method (3~5 months was mostly in meetings and very basic prototyping) and using a test-first approach (their own flavor of TDD). The 'go live' day was to occur at 3:00AM and mandatory that nearly the entire department be on-sight (including the department VP) and available to help troubleshoot any system issues.

3:00AM - Teams start their deployments
3:05AM - Thousands and thousands of errors from all kinds of sources (web exceptions, database exceptions, server exceptions, etc), site goes down, teams roll everything back.

3:30AM - The primary developer remembered he made a last minute change to a stored procedure parameter that hadn't been pushed to production, which caused a side-affect across several layers of their stack.

4:00AM - The developer found his bug, but the manager decided it would be better if everyone went home and get a fresh look at the problem at 8:00AM (yes, he expected everyone to be back in the office at 8:00AM).

About a month later, the team scheduled another 3:00AM deployment (VP was present again), confident that introducing mocking into their testing pipeline would fix any database related errors.

3:00AM - Team starts their deployments.
3:30AM - No major errors, things seem to be going well. High fives, cheers..manager tells everyone to head home.
3:35AM - Site crashes, like white page, no response from the servers kind of crash. Resetting IIS on the servers works, but only for around 10 minutes or so.
4:00AM - Team rolls back, manager is clearly pissed at this point, "Nobody is going fucking home until we figure this out!!"
6:00AM - Diagnostics found the WCF client was causing the server to run out of resources, with a mix of clogging up server bandwidth, and a sprinkle of N+1 scaling problem. Manager lets everyone go home, but be back in the office at 8:00AM to develop a plan so this *never* happens again.

About 2 months later, a 'real' development+integration environment (previously, any+all integration tests were on the developer's machine) and the team scheduled a 6:00AM deployment, but at a much, much smaller scale with just the 3 development team members.

Why? Because the manager 'froze' changes to the ASPX service, the web team still needed various enhancements, so they bypassed the service (not using the ASPX service at all) and wrote their own SQL scripts that hit the database directly and utilized AppFabric/Velocity caching to allow the site to scale. There were only a couple client application using the ASPX service that needed to be converted, so deploying at 6:00AM gave everyone a couple of hours before users got into the office. Service deployed, worked like a champ.

A week later the VP schedules a celebration for the successful migration to WCF. Pizza, cake, the works. The 3 team members received awards (and a envelope, which probably equaled some $$$) and the entire team received a custom Benchmade pocket knife to remember this project's success. Myself and several others just stared at each other, not knowing what to say.

Later, my manager pulls several of us into a conference room
Me: "What the hell? This is one of the biggest failures I've been apart of. We got rewarded for thousands and thousands of dollars of wasted time."
<others expressed the same and expletive sediments>
Mgr: "I know..I know...but that's the story we have to stick with. If the company realizes what a fucking mess this is, we could all be fired."
Me: "What?!! All of us?!"
Mgr: "Well, shit rolls downhill. Dept-Mgr-John is ready to fire anyone he felt could make him look bad, which is why I pulled you guys in here. The other sheep out there will go along with anything he says and more than happy to throw you under the bus. Keep your head down until this blows over. Say nothing."

My devGoals for 2018:
- Build a RESTful API with NodeJS just for learning.
- Finish my first product (electronics sideproject).
- Convert more people to use CraftCMS or at least not use Joomla or WP.
- Get a raise.
- Add Continuous Integration to more projects.
- Add more unit testing where appropriate.
- Create and release a mobile app.

To be continued...
*playing to be continued meme sound*

So just about to head to the pub and I got the dreaded call from my boss.

The support team had developed some fixes. They "tested" and deployed without letting us know... And you guessed it there was failures all over the shop!

So it turned out their testing was running on a local base install with no integration compared to the live system with 15 years of customisation and complex integration. My they thought this was acceptable I don't know...

And the best part was the developers who made the changes didn't understand their own code (I found the tutorial they copied online) they just blindly copied it without understanding how it worked!

So 4 hours later we found the bug, nothing like having a query and s SQL connection but not executing the query....

There goes my Saturday evening. Now we're was my beer!

Sometimes the testers do a good job, sometimes.. 😂😂

Old boss story. This guy was nice but a terrible boss. Also relevant, he has a background in IT so should know better.

Him: So when you wanna check a password is correct you just unhash it in the database?
Me: *facepalm*

Me: Hey we should be doing unit and integration testing at a minimum to lower bugs.
Him: We don't need those, we're not a bank. If a problem comes up we just fix it and push to production.
(A while later)
Him(in email): Why do we keep getting bugs reported. Don't you devs test your code.

I was mildly annoyed at that one.

Him: We're always over budget on projects, how can we fix this.
Me: What if we increase our quotes.(technically there are other ways as well but not really possible at that time)
Him: We can't do that, clients won't want to pay.

Me: *finishing off my handover as I'm leaving for a new job*
Him: Wow you do a lot of work

- Be me (Dev)
- Develop website for client that has an online payment integration.
- Notice there is no one for QA and testing.
- Try to raise voice about it but get shot down by management.
- Get order to push the project to production (because the deadline has arrived, therefore the project must be ready)
- Production performance has an error margin of 15% (customers getting their card over/under charged)
- Get blamed and flamed for everything cuz well, its all the dev's fault.

FML

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

Introduced a ‘new’ logging framework for our web site. Web team is testing the integration and I get an email saying the logging wasn’t working. Instead of sending me how she is searching the logs, she sends me a screen shot of the code (which is ass-backwards of how I documented the logging library, but that’s another rant). OK, she wrote 5 lines of code that should be one line, but OK, the error still should have logged fine. I search the logs, and sure enough, there they are. Errors logged just as they should.
So I email back (with screenshot of the search query and results) asking how she searched for the errors.
Hour later she responds ..”I don’t know.”
That’s it.
WTF do you mean “I don’t know”?…WTF…you are a –bleep-ing developer too! This is not the first –bleep-ing splunk query you’ve written!
OK..I’m calm..feeling better. Wouldn’t be so bad if she emailed just me with the question (I’m not a splunk query expert either, we can figure it out together), but she was sure to cc 3 of the PMs involved in the integration, my boss, and other team members to make it sound like the problem was my code.

So here's the deal. I am a team lead of a small company and I have a junior who is an idiot. I mean literally, idiot. We code in Python mostly and as Python is not structured as a default Java or C# project, the developer needs to be very careful so that the structure (or tiers) is maintained properly.

Now this girl, always messes up the tiers. Say one enhancement can be easily implemented in the UI tier, she would do the implementation in the core Db access layer, which may complete this particular enhancement, but breaks all the other functions (sometimes the whole project) connected to that particular module of the Db layer. She doesn't do any integration testing after updating the code, she only checks the current enhancement she is working on. When the enhancement goes to the testing phase, the testers find those broken functions and that results a re-work (most of the times done by me).

I have warned her. Even our manager has warned her. She always tells that she is working to improve herself. But I know, she isn't. She mostly chats with her boyfriends (yes, with an 's') when she has no work to do. She never upgrades herself or works on her skills.

I can easily report about her, and they will fire her without any warning (they did it already with a guy earlier). I don't want to do that again. What should I do? Any suggestions?

Oh, she has a great ego. She thinks that knows and understands everything. She will listen to your suggestions carefully, but will never follow those.

Worst collaboration experience story?

I was not directly involved, it was a Delphi -> C# conversion of our customer returns application.

The dev manager was out to prove waterfall was the only development methodology that could make convert the monolith app to a lean, multi-tier, enterprise-worthy application.

Starting out with a team of 7 (3 devs, 2 dbas, team mgr, and the dev department mgr), they spent around 3 months designing, meetings, and more meetings. Armed with 50+ page specification Word document (not counting the countless Visio workflow diagrams and Microsoft Project timeline/ghantt charts), the team was ready to start coding.
The database design, workflow, and UI design (using Visio), was well done/thought out, but problems started on day one.
- Team mgr and Dev mgr split up the 3 devs, 1 dev wrote the database access library tier, 1 wrote the service tier, the other dev wrote the UI (I'll add this was the dev's first experience with WPF).
- Per the specification, all the layers wouldn't be integrated until all of them met the standards (unit tested, free from errors from VS's code analyzer, etc)
- By the time the devs where ready to code, the DBAs were already tasked with other projects, so the Returns app was prioritized to "when we get around to it"

Fast forward 6 months later, all the devs were 'done' coding, having very little/no communication with one another, then the integration. The service and database layers assumed different design patterns and different database relationships and the UI layer required functionality neither layers anticipated (ex. multi-users and the service maintaining some sort of state between them).

Those issues took about a month to work out, then the app began beta testing with real end users. App didn't make it 10 minutes before users gave up. Numerous UI logic errors, runtime errors, and overall app stability. Because the UI was so bad, the dev mgr brought in one of the web developers (she was pretty good at UI design). You might guess how useful someone is being dropped in on complex project , months after-the-fact and being told "Fix it!".

Couple of months of UI re-design and many other changes, the app was ready for beta testing.

In the mean time, the company hired a new customer service manager. When he saw the application, he rejected the app because he re-designed the entire returns process to be more efficient. The application UI was written to the exact step-by-step old returns process with little/no deviation.

With a tremendous amount of push-back (TL;DR), the dev mgr promised to change the app, but only after it was deployed into production (using "we can fix it later" excuse).

Still plagued with numerous bugs, the app was finally deployed. In attempts to save face, there was a company-wide party to celebrate the 'death' of the "old Delphi returns app" and the birth of the new. Cake, drinks, certificates of achievements for the devs, etc.

By the end of the project, the devs hated each other. Finger pointing, petty squabbles, out-right "FU!"s across the cube walls, etc. All the team members were re-assigned to other teams to separate them, leaving a single new hire to fix all the issues.

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

Inherited a simple marketplace website that matches job seekers and hospitals in healthcare. Typically, all you need for this sort of thing is a web server, a database with search

But the precious devs decided to go micro-services in a container and db per service fashion. They ended up with over 50 docker containers with 50ish databases. It was a nightmare to scale or maintain!

With 50 database for for a simple web application that clearly needs to share data, integration testing was impossible, data loss became common, very hard to pin down, debugging was a nightmare, and also dangerous to change a service’s schema as dependencies were all tangled up.

The obvious thing was to scale down the infrastructure, so we could scale up properly, in a resource driven manner, rather than following the trend.

We made plans, but the CTO seemed worried about yet another architectural changes, so he invested in more infrastructure services, kubernetes, zipkin, prometheus etc without any idea what problems those infra services would solve.

Spent a lot of time designing a proper HTTP (dare I even say RESTful) API for our - what is until now a closed system, using a little-known/badly-supported message-over-websocket protocol to do RPC-style communications - supposedly enterprise-grade product.

I make the API spec go through several rounds of review with the rest of the dev team and customers/partners alike. After a few iterations, everybody agrees that the spec will meet the necessary requirements.

I start implementing according to spec. Because this is the first time we're actually building proper HTTP handling into the product, but we of course have to make it work at least somewhat with the RPC-style codebase, it's mostly foundational work. But still, I manage to get some initial endpoints fully implemented and working as per the spec we agreed. The first PR is created, reviews are positive, the direction is clear and what's there already works.

At this point in time, I leave on my honeymoon for two weeks. Naturally, I assume that the remaining endpoints will be completed following the outlines/example of the endpoints which I built. When I come back, the team mentions that the implementation is completed and I believe all is well.

The feature is deployed selectively to some alpha customers to start validation testing before the big rollout. It's been like that for a good month, until a few days ago when I get a question related to a PoC integration which they can't seem to get to work.

I start investigating and notice that the API hasn't been implemented according to the previously agreed upon spec at all. Not only did the team manage to implement the missing functionality in strange and some even broken ways, they also managed to refactor my previously working endpoints into being non-compliant.

Now, I'm a flexible guy. It's not because something isn't done exactly as I've imagined it that it's automatically bad. However, I know from experience that designing a good/clear/future-proof API is a tricky exercise. I've put a lot of time and effort into deliberate design decisions that made up the spec that we all reviewed repeatedly and agreed upon. The current implementation might also be fine, but I now have to go over each endpoint again and reason about whether the implementation still fulfills the requirements (both soft and hard) that we set out to meet.

I'm met with resistance, pushback and disbelief from product management and dev co-workers alike when I raise the concern that the API might actually not be production-ready (while I'm frantically rewriting my integration tests and figuring out how the actual implementation works in comparison to what was spec'ed).

Oh, and did I mention that product management wants to release this by end-of-week?!

Just received a test for a job I'm interviewing for. I was interviewing for a C++ position. Practice test: Create an REST API using SpringBoot, Spring Data, document with Swagger and implement continuous integration testing.

To be fair, I also mentioned I'm fluent in Java. But I've never touched SpringBoot or done any backend webdev, since my intention was to never get near it.

Deadline: Sunday. Game on...

Don't worry dear customer. I will mount it for you. I I'm an engineer

The "unit" in unit test does not mean your ENTIRE APPLICATION. Ever heard of scope!?

I am amazed how often people write overblown test setups, mock hundreds of unrelated services, just to test one tiny bit of logic.

That bit of logic could have been a pure function.

For that pure function you could write a dead simple unit test. Given that input, I expect that output. Nothing more, nothing less. (It helps even more if the pure functions only accepts primitives, like string and numbers, or very simple immutable value objects).

No I don't care that the service is used by another service, as your mocked interaction also doesn't test the service as a whole but you just assume the happy case most of the time anyway. You want to test the entire application? Let's not use unit tests for that but let's use a different kind of test for that (integration test, functional tests, e2e-tests).

If you write code in a way that easily allows for unit testing, your need to mock goes away.

I'm testing Siri integration with Uber and this came up

Longest I've worked without rest + why?

Over 24 hours. Why?

In our old system, the database had fields, for example, a customer like Total97, Total98, etc. to store values by year (or some date-specific value).

Every January 1, we had to add fields to accommodate the upcoming year and make the appropriate code changes to handle the new fields.

One year the UPS shipping rates changed and users didn't want to 'lose' the old rates, so they wanted new fields added (Rate98, Rate99, etc) so they could compare old vs. new. That required a complete re-write of most of the underlying applications because users wanted to see the difference on any/all applications that displayed a shipping rate. I'll throw in asking 'why?' was often answered with "because we pay you to do what we say". Luckily, we had already gotten to work on a lot of this before January 1st, so we were, for the most part, ready.

January 1st rolls around (we had to be in the office at 3:00AM), work thru changes, spend some time testing, and be done before noon. That didn't happen. The accounting system was a system that wasn't in (and had never been) in scope, and when we flipped the switch, one of the accountants comes into the office:
E: "Guys? None of our Excel spreadsheets are working. They are critical to integration with the accounting software"
Us: "What? Why would you be using Excel to integrate with the software instead of their portal?"
E: "We could never figure it out, so we had a consultant write VBA scripts to do the work."
Us: "OK, a lot of fields changed, but shouldn't be a big deal. How many spreadsheets are we talking about?"
E: "Hundreds. We have a separate spreadsheet for every integration point. The consulting company said it scalable, whatever that means."
Us: "What?! Why we just know hearing about this!?"
E: "Don't worry, the consultant said making changes would be easy, let me show you, just open the spreadsheet..click here..<click><click><click>...ignore that error, it always happens...click that <click><click><click>.."
Us: "Oh good lord, this is going to take hours"
E: "Ha! Probably. All this computer stuff is your job and I've got a family to get to. Later"
Us: "Hey 'VP of IS', can we go home and fix these spreadsheets as-needed this week?"
VP-IS: "Let me check with 'VP-FS'"
<few minutes later>
VP-IS: "No, he said Excel is critical to running their department. We stay until Excel is fixed."
Us: "No, no...its these spreadsheets. I doubt FS needs all of them tomorrow morning."
VP-IS: "That's what I said. Spreadsheets, Excel, same thing. I'll order the pizza. Who likes pepperoni!?"

At least he didn't cheap out on the pizza (only 4 of us and he ordered 6 large, extra pepperoni from one of the best pizza places in town)

One problem after another and we didn't get done until almost 6:00AM. Then...

VP-IS: "Great job guys. I've scheduled a meeting at 8:00AM to review what we did so we can document the process for next year. You've got a couple of hours. Feel free to get some breakfast and come back, or eat the left over pizza in the breakroom fridge. There is a lot left"
Us: "Um...sorry...we're going home."
VP-IS: "WHAT!!...OK...fine. I'll schedule the meeting for 12"
Us: "No...we're going home. We'll see you tomorrow."

I started my actual gig as CTO of construction group (Innovation Hub) a year ago. And it was a hell of a ride, implementing kind of a scrum-ban for project management, XP, peer-reviews, a git-flow, git commit message formats, linters, unit testing, integration tests, etc...
And it's the fun part because with the CIO we had to drive the board to do A LOT of changes in their IT/Innovation drive.

But in one year there is a lot of KPI that went up :
* Deployment: When I arrived it took three stressful days to deploy a new version of one application, once a month. Today we do it every week, and it takes three annoying hours.
* We had no test. NOTHING! Today we have 85% code coverage for the unit test, and automatic integration tests run by our CI server every day.
* We had almost no documentation. Today our code is our documentation (it automatically extracted and versioned).
* We had 0 add value in the use of git. With commit messages as "dev", "asked task", inside jokes and a lot of "fix" and "changes". Today we have a useful git, and we even use it to create our deploy changelogs (and it's only mildly annoying!).
* More important, the team is happy! They get their purpose, see betterment in their tech mastery. They started doing conception, applicative architecture, presentations, having fun.

There is still a LOT of bad things we are still working on, and trying to solve (support workflow and betterment). But seeing what they already did, I'm so proud of my TEAM! I'm a fucking asshole, workaholic, "just do it" kind of guy. But they managed to achieve so much. Fucking PROUD!!

I seriously cannot stress how important it is to build good reliable tests. Especially regression testing.

I am crying inside over the amount of time I've lost in my integration hell.

Seriously stupid shit that should have been tested but never did because I was too fucking lazy. Don't be me. Don't put yourself in the hell I'm in. Be better.

lol, I just got an email from HBO Max that said, "this email template is for integration testing only."

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?

Most intense day for me was at the very start of my career. Internship... went with product manager to client's office while PM installed new test version of our product for on-site integration testing. Shortly after deploy, client manager came over to ask why production had gone down...

Turns out that manually typing DB name as part of deployment script is not, erm, risk free. PM entered production DB name and took out a very busy call centre for a few hours. Agents in tears, customers raging on phones, etc! After we restored and got everything back up and running, he reached me the keyboard and said "You're doing it this time."

My attempt was problem free, thankfully. Earned many brownie points that day.

Testing had some issues with system integration. I asked them what their setup was.

Answer: "Almost similar to the real hardware."

LMAO!

Tl;Dr Im the one of the few in my area that sees sftping as the prod service account shouldn't be a deployment process. And the ONLY ONE THAT CARES THAT THIS IS GONNA BREAK A BUNCH OF SHIT AT SOME POINT.

The non tl;dr:

For a whole year I've been trying to convince my area that sshing as the production service account is not the proper way to deploy and/or develop batch code. My area (my team and 3 sister teams) have no concept of using version control for our various Unix components (shell scripts and configuration files) that our CRITICAL for our teams ongoing success. Most develop in a "prodqa like" system and the remainder straight in production. Those that develop straight in prodqa have no "test" deployment so when they ssh files straight to actual production. Our area has no concept of continuous integration and automated build checking. There is no "test cases", no "systems testing" or "regression testing". No gate checks for changing production are enforced. There is a standing "approved" deployment process by the enterprise (my company is Whyyyyyyyyyy bigger than my area ) but no one uses it. In fact idk anyone in my area who knows HOW to deploy using the official deployment method. Yes, there is privileged access management on the service account. Yes the managers gets notified everytime someone accesses the privileged production account. The managers don't see fixing this as a priority. In fact I think I've only talk to ONE other person in my area who truly understands how terrible it is that we have full production change access on a daily basis. Ive brought this up so many times and so many times nothing has been done and I've tried to get it changed yet nothing has happened and I'm just SO FUCKING SICK that no one sees how big of a deal this. I mean, overall I live the area I work in, I love the people, yet this one glaring deficiency causes me so much fucking stress cause it's so fucking simple to fix.
We even have an newer enterprise deployment. Method leveraging a product called "urban code deploy" (ucd) to deploy a git repository. JUST FUCKING GIT WITH THE PROGRAM!!!!..... IT WAS RELEASED FUCKING 12 YEARS AGO......

Please..... Please..... I just want my otherwise normally awesome team to understand the importance and benefits of version control and approved/revertable deployments

Testing? Continuous Integration? Watdat? Never heard of it
: ^]

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

¡rant|rant

Nice to do some refactoring of the whole data access layer of our core logistics software, let me tell an story.

The project is around 80k lines of code, with a lot of integrations with an ERP system and an sql database.

The ERP system is old, shitty api for it also, only static methods through an wrapper to an c++ library

imagine an order table.

To access an order, you would first need to open the database by calling Api.Open(...file paths) (yes, it's an fucking flat file type database)

Now the database is open, now you would open the orders table with method Api.Table(int tableId) and in return you would get an integer value, the pointer.

Now for the actual order. first you need to search for it by setting the search parameter to the column ID of the order number while checking all calls for some BS error code

Api.SetInt(int pointer, int column, int query Value)
Then call the find method.

Api.Find(int pointer)

Then to top this shitcake of an api of: if it doesn't find your shit it will use the "close enough" method of search.

And now to read a singe string 😑

First you will look in the outdated and incorrect documentation given to you from the devil himself and look for the column ID to find the length of the column.

Then you create a string variable with ALL FUCKING SPACES.

Now you call the Api.GetStr(int pointer, int column, ref string emptyString, int length)

Now you have passed your poor string to the api's demon orgy by reference.

Then some more BS error code checking.

Now you have read an string value 😀

Now keep in mind to repeat these steps for all 300+ columns in the order table.

News from the creators: SQL server? yes, sql is good so everything will be better?

Now imagine the poor developers that got tasked to convert this shitcake to use a MS SQL server, that they did.

Now I can honestly say that I found the best SQL server benchmark tool. This sucker creams out just above ~105K sql statements per second on peak and ~15K per second for 1.5 second to read an order. 1.5 second to read less than 4 fucking kilobytes!

Right at that moment I released that our software would grind to an fucking halt before even thinking about starting it. And that me & myself and I would be tasked to fix it.

4 months later and two weeks until functional beta, here I am. We created our own api with the SQL server 😀

And the outcome of all this...

Fixes bugs older than a year, Forces rewriting part of code base. Forces removal of dirty fixes. allows proper unit and integration testing and even database testing with snapshot feature.

The whole ERP system could be replaced with ~10 lines of code (provided same relational structure) on the application while adding it to our own API library.

Best part is probably the performance improvements 😀. Up to 4500 times faster and 60 times less memory usage also with only managed memory.

Hacking company product with reverse engineering ang bytecode instrumentation.

The project I had to write integration test for was really not meant/written for testing. I ended up bytecode instrumenting an internal library to intercept the needed states and results.

My boss is one of those og compsci guys that’s in his sixties writing code since his 20s. He’s usually highly competent... which is why I almost fell out of my chair laughing when he force killed the integration testing instance with all the clients connected thinking he was in the simulated environment

Following my first rant, my boss had the brilliant idea of running the old and the new architecture in parallel. I had advised that it won’t be ideal since the same Scala code was ingesting into 2 different Kinesis streams and one was running an old KCL written in Java where as other was consumed by a Firehose delivery stream(eventually we will be ingesting it into Firehose directly). I had told few manual + automated tests on Code as well as from a functionality of the new architecture and a set of tests for checking the integration of the new Producer code with Consumer.

The statement I got from my boss was “This is the test, we test it on production in parallel”. My boss had a brilliant idea to fucking test the new code on the production directly but running them in parallel without accounting for undefined behaviour it might cause in the current production system. I mean my boss should get a Nobel peace prize for shattering our mental peace.

Anywho, we started the deployment today at 5AM in the morning. I had all the aws services deployed. Was just waiting to deploy the new Collector code which we did at 5AM. Immediately after 5 minutes the system went bonkers, there was fire, blood, demons and I was smoking a cigarette with the biggest “I told you so smile” on my face. I’ve just written an email to my boss and have told him calmly that “Listen motherfucker, 90 percent of the software companies aren’t idiots to focus on testing and quality. We need to start spending time on testing and quality else we’ll again be in the same soup after few weeks again”.waiting for his reply

When the CTO/CEO of your "startup" is always AFK and it takes weeks to get anything approved by them (or even secure a meeting with them) and they have almost-exclusive access to production and the admin account for all third party services.

Want to create a new messaging channel? Too bad! What about a new repository for that cool idea you had, or that new microservice you're expected to build. Expect to be blocked for at least a week.

When they also hold themselves solely responsible for security and operations, they've built their own proprietary framework that handles all the authentication, database models and microservice communications.

Speaking of which, there's more than six microservices per developer!

Oh there's a bug or limitation in the framework? Too bad. It's a black box that nobody else in the company can touch. Good luck with the two week lead time on getting anything changed there. Oh and there's no dedicated issue tracker. Have you heard of email?

When the systems and processes in place were designed for "consistency" and "scalability" in mind you can be certain that everything is consistently broken at scale. Each microservice offers:

1. Anemic & non-idempotent CRUD APIs (Can't believe it's not a Database Table™) because the consumer should do all the work.
2. Race Conditions, because transactions are "not portable" (but not to worry, all the code is written as if it were running single threaded on a single machine).
3. Fault Intolerance, just a single failure in a chain of layered microservice calls will leave the requested operation in a partially applied and corrupted state. Ger ready for manual intervention.
4. Completely Redundant Documentation, our web documentation is automatically generated and is always of the form //[FieldName] of the [ObjectName].
5. Happy Path Support, only the intended use cases and fields work, we added a bunch of others because YouAreGoingToNeedIt™ but it won't work when you do need it. The only record of this happy path is the code itself.

Consider this, you're been building a new microservice, you've carefully followed all the unwritten highly specific technical implementation standards enforced by the CTO/CEO (that your aware of). You've decided to write some unit tests, well um.. didn't you know? There's nothing scalable and consistent about running the system locally! That's not built-in to the framework. So just use curl to test your service whilst it is deployed or connected to the development environment. Then you can open a PR and once it has been approved it will be included in the next full deployment (at least a week later).

Most new 'services' feel like the are about one to five days of writing straightforward code followed by weeks to months of integration hell, testing and blocked dependencies.

When confronted/advised about these issues the response from the CTO/CEO
varies:

(A) "yes but it's an edge case, the cloud is highly available and reliable, our software doesn't crash frequently".
(B) "yes, that's why I'm thinking about adding [idempotency] to the framework to address that when I'm not so busy" two weeks go by...
(C) "yes, but we are still doing better than all of our competitors".
(D) "oh, but you can just [highly specific sequence of undocumented steps, that probably won't work when you try it].
(E) "yes, let's setup a meeting to go through this in more detail" *doesn't show up to the meeting*.
(F) "oh, but our customers are really happy with our level of [Documentation]".

Sometimes it can feel like a bit of a cult, as all of the project managers (and some of the developers) see the CTO/CEO as a sort of 'programming god' because they are never blocked on anything they work on, they're able to bypass all the limitations and obstacles they've placed in front of the 'ordinary' developers.

There's been several instances where the CTO/CEO will suddenly make widespread changes to the codebase (to enforce some 'standard') without having to go through the same review process as everybody else, these changes will usually break something like the automatic build process or something in the dev environment and its up to the developers to pick up the pieces. I think developers find it intimidating to identify issues in the CTO/CEO's code because it's implicitly defined due to their status as the "gold standard".

It's certainly frustrating but I hope this story serves as a bit of a foil to those who wish they had a more technical CTO/CEO in their organisation. Does anybody else have a similar experience or is this situation an absolute one of a kind?

I only expect two (2) things guaranteed in year 2019: test and compilation errors

We are 1 week from first system demo of a down well seismic system. All the SW to run on the sensor nodes inside the well pipe has been developed with driver mockups since the FPGA team hasn't finished their part yet. So, integration, integration testing, system test and bug fix must be done in a hurry! Does this scenario sound familiar?

When you have only done unit testing and not integration testing.

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

Halp

PM: "We would like our automated testing / continuous integration in AWS"

Me: *Army crawling towards Jenkins with my last dying breath*

Today I spent 9 hours trying to resolve an issue with .net core integration testing a project with soap services created using a third party soap library since .net core doesn't support soap anymore. And WCF is before my time.

The tests run in-process so that we can override services like the database, file storage, basically io settings but not code.

This morning I write the first test by creating a connected service reference to generate a service client. That way I don't need to worry about generating soap messages and keeping them in sync with the code.

I sent my first request and... Can't find endpoint.

3 hours later I learn via fiddler that a real request is being made. It's not using the virtual in-process server and http client, it's sending an actual network request that fiddler picks up, and of course that needs a real server accepting requests... Which I don't have.

So I start on MSDN. Please God help me. Nope. Nothing. Makes sense since soap is dead on .net core.

Now what? Nothing on the internet because above. Nothing in the third party soap library. Nothing. At this point I question of I have hit my wall as a developer.

Another 4 hours later I have reverse engineered the Microsoft code on GitHub and figured out that I am fucked. It's so hard to understand.

2 more hours later I have figured out a solution. It's pure filth..I hide it away in another tooling project and move all the filth to internal classes :D the equivalent of tidying your room as a kid by shoving it all under the bed. But fuck it.

My soap tests now use the correct http client with the virtual server. I am a magician.

Not entirely sure if it counts, but Postman.

Used to be a simple, yet efficient tool for integration testing. And nothing more. Now it's a bloated, convoluted resource eating piece of bling-bling that tries to do a shitload of stuff, but only does them in a mediocre way.

Meh, while I was typing this I realized what a comfortable life I lead if I complain about something like this. Oh, the perks of being a middle class white man working in the tech sector...

I just reviewed a pull request with a test case like (pseudo code):

# Test MyService

const mock = createMock(myService.myMethod)
.whenCalledWith("foo")
.returns("bar");
assert(mock.myMethod("foo") === "bar"));

Why though? Why are we testing the mock? What is happening here? This test has no reason of being there instead of a fuzzy feeling that we now have unit test to lure us into a false sense of security.

I asked why we don't do an integration test. Response was: "They are slow."

Well, duh, but at least they would actually test something.

What do you gain by asserting that the mock is working the way you set it up?

so we just had the software engineering exam and my teacher is posting the "best answers" he got...this is one of them

It is 4:08 am here, I am supposed to complete my first task as an intern by tomorrow night(technically tonight) and here I am on devRant.

Plot twist: I already did the job. It was writing test cases ffs. 😕

VP last week: No you can't have that equipment that fakes out the gps. It's very expensive and not in the budget. Just run valgrind and push your code so we can deploy it.
VP in today's all hands: Guys, if you need test equipment, come ask for it and we'll get you what you need. Not having equipment is not a valid excuse for skipping integration testing.

I'm an iOS developer and I cringe when I read job specs that require TDD or excessive unit testing. By excessive I mean demanding that unit tests need to written almost everywhere and using line coverage as a measure of success. I have many years of experience developing iOS apps in agencies and startups where I needed to be extremely time efficient while also keeping the code maintainable. And what I've learned is the importance of DRY, YAGNI and KISS over excessive unit testing. Sadly our industry has become obsessed with unit tests. I'm of the opinion that unit tests have their place, but integration and e2e tests have more value and should be prioritised, reserving unit tests for algorithmic code. Pushing for unit tests everywhere in my view is a ginormous waste of time that can't ever be repaid in quality, bug free code. Why? Because leads to making code testable through dependency injection and 'humble object' indirection layers, which increases the LoC and fragments code that would be easier to read over different classes. Add mocks, and together with the tests your LoC and complexity have tripled. 200% code size takes 200% the time to maintain. This time needs to be repaid - all this unit testing needs to save us 200% time in debugging or manual testing, which it doesn't unless you are an absolute rookie who writes the most terrible and buggy code imaginable, but if you're this terrible writing your production code, why should your tests be any better? It seems that especially big corporate shops love unit tests. Maybe they have enough money and resources to pay for all these hours wasted on unit tests. Maybe the developers can point their 10,000 unit tests when something goes wrong and say 'at least we tried'? Or maybe most developers don't know how to think and reason about their code before they type, and unit tests force them to do that?

Ask someone for their Java windows service and installation instructions for testing our integration. They reply with info on how to install Java.

If I had a dev superpower, it'd be the ability to wave my hand to make integration tests and unit tests appear. Seriously, they're necessary, but also painful to write

When you spend hours in a messy codebase to fix a bug properly and add an integration spec to cover that specific case.
And even you do a round of testing on staging + providing screenshots, there is always someone on the team that will write in your PR, "It works, I tested the change on my machine".
I understand that some people are skeptical but to the point of not trusting integration tests + screeshots/recordings then please test it on staging or production next time because if it works on your machine doesn't mean it will work there ;)

Started adding new MVC project to main solution at work. Started getting assembly reference errors across the projects during testing. Figured I might as while update the few assemblies that are complaining instead of trying to downgrade to maintain the current state of things. Shouldn't take too long right?....8 hours of staring at configs and running and rerunning nuget commands to get all the versions lined up across 120 projects....thank God we have extensive unit and integration tests...

What a mess ^^

From one moment to another unit-tests on my local machine stopped working.

There was a PHP fatal error, because of insufficient memory.

Actually, there was a ducking "unit"-test of a controller action "log".

This action returns the content of the projects log file...

Since this log file grew over the time, PHP tried to assert the response of the controller action which was sized about 400MB.

C'moooooon guys!
What were your thoughts behind this bullshit? ^^

Is it actually required to write unit tests in microservices?
every time i write them it feels like im just redundantly copying a method...
Dont get me wrong, im not against testing, I am using test environments, integration tests and mocks, but unit test seem kinda redundant to me.

I can see light at the end of the tunnel, IT BUUUURNNNNSSS

Two data pipelines, right before integration testing :)

An integration test is testing the real db (production twin or similar) or an in-memory db?

My main project in work is making program in C# (right now .NET Standard) that can read scans of invoices that are sent from contractors. I'm working on it for almost two years now (with breaks and only halftime because university). Alone. And for last two months I've been redesigning, refactoring and making whole app "better", using experience and knowledge gained in the last two years.

Obviously my boss wasn't happy with that but I got him to accept it, promising that it'll make it work faster, expansion will be simpler and I'll make core as a separate library that can be used anywhere, not only in the JobRouter ecosystem.

And so I reworked most of the code, made it cleaner, I hope, and a tad quicker. And I was happy with it while testing on a package of invoices. Today I made first integration with customer's JobRouter.

The results aren't any better - in some cases they are much worse. Especially while searching for invoice entries, which can be in any shape or form and on any of document's pages.

I guess, being a Junior, I wasn't really up to the task. I'm sick of working on a "guessing" program that has to work with every invoice template users can imagine. I'm sick of not getting any recognition for what I did good. And I'm sick of constantly being pushed to make it work better when I just don't have any more ideas or my skills are just lacking.

To be honest, I don't know what to do. I'll probably have to work on making it search the data better. But it's not trivial to just look at the code and see errors. Iterating on the code while working with different invoices worked for a bit in older versions, but I reached the point where changes made to make one invoice be read better, made another one worse.

Its like on those GIFs where you squish one bug to make another two appear.

So yeah, I'm currently really doubting my career, skills and intelligence.

#Rant

When someone decides to alter the UI and replace replace buttons with glyphicons with zero id's or anything and Breaks the UI integration testing project and doesnt even realise.!

FML on a Friday pre testing env release 2!

so management implements SDLC. finally. but here is the snag... none of the environments are setup for any developer , integration or uat testing. now all the while business keeps pushing changes knto us and making us try work miracles. anyone else have this hell of communication from the high holy management above not listening to developers concerns ?

Fuck my integration tests. They fail everytime in another way. Every computer restart other gremlins get into the machine and fuck up the tests another way. I've got no fuckin idea where to even start....

Airflow… airflow… I hate you so freaking much, you are a bloated piece of software that packages wayyy too much and increase the complexity of any solution we built on top of you. Plus unit-testing and integration tests are wayyy too difficult with you. But man… your recent UI changes are a massive welcome.

A year ago I was tasked with either upgrading airflow to version 2 or to migrate the code to another tool. Naively I thought “well might as well upgrade to avoid a rewrite”. Little did I know that the reason airflow didn’t scale out well for us, was due to people over the years not having a grasp on airflow primitives like “pools”, “workers” and “operators”. Ended up refactoring the entire codebase for both infra and DAGs anyhow AND upgrading the beast AND lower cost by a factor of 2 (from $100-$150 daily to $50-$70 daily).

But seriously feels like I could’ve solved the scheduling issue with literally any message queue+decent library (like celery or Faust) and I’d have half the headache.

New Project

M: Hey, check these two processes. Both took different paths for the same input. Here are the logs. Both are the same though.
Me: Ok... do we have a debugger?
M: No this product doesn't have a debugger
Me: Any unit tests i should know of?
M: We don't do unit testing. Everything is done in Integration Testing.
Me: Ok. So how can i check the db for this?
M: You can't, the access is restricted. You'll have to raise a ticket to other team with the sql output you need.
Me: Ok. So I hope you have the schema at least.
M: Yes we have the schema. But there was some issue last week so the values might not be there in the correct column. They may or may not be present where they are supposed to be.

Wtf am i supposed to do... fucking play football on ticketing system with the other team 😐

I am working on an event driven system that uses a message bus and has a few services that talk to each other asynchronously via the bus.

I'm writing in memory integration tests for one of those services, but I just realised the fundamental flaw here with such tests. I only have 1 application running, but I need several. This is quite a serious flaw I should have seen before.

Anyone else tried integration testing event driven distributed services? I imagine all I can do is stub the message broker...

Any easiest way to avoid writing test cases every time in UI integration testing?

TL;DR: Embedded software guy needs to create a multi-instance sandbox environment in Jenkins for testing and not sure what good solutions are out there. Looking for suggestions.

So at work, we have these really cool integration tests that validate our system for flight safety. What's not so cool is that due to factors outside of my control, each test has to be run serially and the entire test suite can take many many hours. This is mostly due to a hardware limitation (not enough physical NICs), but there are other SW factors as well.

What I would like to do is somehow be able to wrap up all the resources into a neat little package and then deploy that package into some kind of virtual environment that can be instantiated on a Jenkins job. The NIC issue would be replaced with a virtual one and *theoretically* I should be able to spawn as many instances of this virtual environment as my CPU and RAM can handle. In short, I want to pseudo parallelize our test suite and drive down our testing time. Somehow I would need to be able to control this entire thing from a script of some sort.

Does anyone know of something out there that would satisfy these kinds of requirements? Double internet points if it's open source.

What the hell am I!? I wonder if you guys can help me...

I've been programming most of my life but I've never actually been a developer by title or job role. I thought maybe if I list what I do and have done someone here could help? I'm sure there are more of you in a similar boat.

- C# and VB dev for some quick DBMS projects to help me understand and mine databases and create a nice simple view for project teams to show findings from the data to help make certain decisions.
- Automating a lot of my colleagues work with Python and if very restricted then just VBA macros in Excel and MSP. This did also include creating tools to gather data during workshops and converting the data for input into other systems.
- Brought Linux to the office with most team members now moving over to Linux with the peace of mind to know that though they do need to try solve their own problems, I can help if need be.
- Had to learn AWS and then implement an autoscaling and load balanced data center installation of a few Atlassian toolsets.
- Creating the architecture diagrams documentation needed for things like the above point.
- Having said that, also have ended up setting up all the Jira/Confluence etc. servers we use and have implemented so far whether cloud (Azure/AWS) or on prem and set up scripts to automate where possible.
- Implemented an automated workflow view in SharePoint based on SP list data and though in an ASPX page, primarily built in JS.
- Building test systems in PHP/JS with Laravel and Angular to help manage integration between systems. Having quite a time right looking into how to build middleware to connect between SOAP and REST API's, the trouble caused more by the systems and their reliance on frameworks we're trying to cut out of the picture.
- Working on BI and MI and training a team to help on the report creation so that I can do the fun creative stuff and then set them to work on the detail :)

Actually it seems safe to say that it seems that though I've finally moved into a dev office (beforehand being the only developer around) I seem to be the one they go to when a strategic solution is needed ASAP and the normal processes can't be followed (fun for someone with a CompSci degree and a number of project management courses under the belt... though I honestly do enjoy the challenges)

But I always end up Jack of all but master of, well hopefully some at least. let's not even get started on the tech related hobbies from circuit design and IoT to Andoid / iOS and game dev and enjoying a bit of pen testing to make sure we're all safe at work and at home.

As much as I don't like boxes, I'm interested to know if there is in fact a box for me? By the way, the above is just a snapshot of my last two years minus the project management work...

COMMITTING only after complete development, testing and integration of a feature

Working along side another consultant house for a client, we have our shit ready weeks ago for integration testing (as was the deadline) against the other guys. We tell them we are ready, but we need them to be ready too, there are some tricky format things and we basically let them spec it out since they integrate further down the line.

They come _NOW_ way over deadline with change requests in message formats, like MOTHERFUCKER, IM ON MY WEEKEND NOW. We KNEW the client wanted it ready next week, thats why we were ready in time. You are not gonna cost me my weekend.

(is what i wanted to say, the devs on the other team are super nice and just absolutely overloaded with work which i cannot help them with)

One thing is certain, tonight my internet access mysteriously dissappears and wont open until monday morning. Such a shame

We got this feature on our app where if you change the status of an action item, it moves down/up to join its brethren of the same status at the bottom of its respective grouping. This is also true for creation.

Problem is: Testing.

I embarked upon this fuckin ridonkulousness today where I had to test all possible scenarios. Empty list, list with only A status, list with only B, list with A and B, list with A and C, etc etc

9 fucking hours later and a lot of anger, I am finally done. I powered back probably 10 club sodas, 6 teas, and had chillstep rollin all day.

If y'all ever feel like giving up because shit's hard, keep pushin. You'll get it eventually ;)

What's the worst part about testing React components? Using the equivalent of fucking stone tools to do your component integration tests! We got errors with no context and errors with no stack trace, just spewing out bullshit! A sample:

The classic "Can't access .root on unmounted test renderer"

The unforgettable and ALWAYS visible "Warning: An update to YourShittyComponent inside a test was not wrapped in act(...)."

We do love it!

Had a 2 hour meeting where I was told to use Specflow for all of our unit and integration testing. It'll be easier for the business to read.

Spent 3 hours setting up the tests for the scenarios for the next story.

Had another 2 hour meeting where they decided it was a bad idea to wrap all unit and integration tests in gherkin...because the business users don't want to read gherkin...

When talking to the integration guys, installing a new testing environment takes about 3 weeks or more.

When a new dev arrive in the team, we set his dev environment in half a day.

I don't understand such a difference.

I got some problem. I work on some company maintaining web application. Every time I add some feature I often accidentally break other features. I read about testing (unit test, integration testing, etc) and ask my project manager and CTO to implement test on our web application but they refused it. The reason is because the web application is already large and it will take a long time to implement. Actually maintain this application is very stressful because it takes along time to add new feature and every time I break something either CEO or Client will scold me. Do you guys have idea/solution to solve this problem?

I am into web development but I handle small projects and I just want to ask does unit testing/Integration testing done by the developer or for testing there is different department? I mean do I need to learn how to write test case too??

How the fuck you define a prototype in Android development?

Is it something like "here is the design showing all possible working and functionality, make a working app with all cloud calls integration in 7 days.

If its working as expected, we will just do some ui enhancements, replace your testing firebase with our own broken cloud, replace default pickers with some library or our own broken pickers and spend 30 days on all this plus the testing"

Is this what you define as a prototype? Like yeah the new intern will do the heavy lifting in all his prototype and then we will start the work on our end, in the meantime giving the intern another new prototype idea and scolding him for delay?

Arrgh...

I need to do a lot of refactoring and testing (%80 percent of which is integration) and ITS SO TEDIOUS!!!

Now, for anyone who says "oh, you write spaghetti code, your code shouldn't be so tedious to refactor". No. It's only tedious because it's a few thousand lines that I've been too lazy to refactor till now, and I need to go through it all.

Anybody have any advice for refactoring or testing in Go?

I am integrating with different third-party payment provider via their API. Just wondering what is the good approach of testing these third party service/API?

Consumer/Producer contract testing?
end-to-end test?

Have to deal with a code that is deployed in integration environments for testing

And someone decided that throwing an exception saying "OK" was a good idea