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.

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

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?

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

Me and my team are working on a system where we depend on a component that was built by a different dev team and hasn't been integration tested yet, because it's that new. This is how it's going..

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

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

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.

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.

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

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

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.

I've been an iOS developer for a number of years now. I like learning new technologies and approaches, but recently I've been getting more and more frustrated by how complex and fast paced everything is becoming.

It used to be that you had to know Objective-C and UIKit and you were set. Then things like unit and ui testing became popular. Swift came out with its set of fancy features and different way of seeing things. Everyone wants to use some sort of architecture. The number of frameworks released just by Apple is mind boggling and getting any sort of exposure to most of them works be a full fine work. Then there is the whole third party ecosystem. There are so many tools and frameworks for everything (which are popular) that I can't even keep up with the new names I keep coming across.

Sure, I can learn new things, I like doing it. However, recently i I've applied to a company and they wanted knowledge of RxSwift. Well, experience, possibly writing a full blown app from beginning to the end. And it had to be highest possible quality, not a kind of "look, I know RxSwift, I can write apps in it, I'll learn more as I go along".

Other place wanted experience in the continuous integration system and ui testing framework that they use. And they expected to to know a lot about one of the many architecture you can use.

Then there is a lot of places that want you to know React Native. Sure, JavaScript is not complicated and the framework simplifies development, but getting to know the tools, creating a toy app, going through a lot of mistakes takes a lot of time. And of course you have to have demonstrable experience in it. Best if you've released an app written in it.

Then you're expected to be involved in the community. Side projects, open source projects. I've been getting the impression that it's becoming more and more about building your personal brand.

In short, I've been getting tired of all of that. It's exciting, but the expectations I find overwhelming. If I start learning a third new thing, I'm going to forget the first one. I miss the simplicity and the clarity of the early days of mobile development.

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

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

Answer: "Almost similar to the real hardware."

LMAO!

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

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.

Me: Spend lots of free time (evenings, weekends, sometimes even mornings) learning new languages, new architectures, new libraries. A lot of effort so I'm at the top of the current tech. Swift, Kotlin, MVVM, MVP, C++, functional programming, reactive programming, continuous integration, unit testing...

Get a new job - once again I have to clean up some shitty code, written by someone who went from Java script to objective c, without reading a single book on iOS development. Unused code, commented out code, redundant code, dead code. Unused assets that no one could be bothered to remove for the past 2 years.

Sometimes I wonder why do I even bother if all I ever do is maintain mess done with outdated tech by someone who couldn't give a 🐙🐙🐙

Tests are great. Used to work for {{probably shouldn't disclose company name}} and the only test was "Look, this one thing did what I thought it would!" when you finished coding a feature. Everything else was just a very shallow smoke test manually preformed by someone who hated their job. Now I work for Veterans United. Unit test all the things, all the time. First. Actual TDD here folks. Now, when you code a feature you can run all the unit tests, integration tests, and then smoke test it! We even have a bunch of UI tests if you feel like running them (mostly in Selenium, but some Protractor and now Nightmare). It's crazy. Having worked for the first company, I thought unit testing sounded horrible. Why would I want to do that? Now, working at VU, I'm like "Unit test all the things!" Things work, and I know it. More importantly, I can prove it. Great shit!

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

Employer made me delete a CI script that checked if our Gulp compiled because a colleague convinced him that “if you upload broken code to git you shouldn’t be uploading it” ..do you even know what CI is for? Don’t you know that people will inevitably fuck up eventually? I want to rip my fucking hair out right now.

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

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

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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.

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