The university system is fucked.

I've been working in this industry for a few years now, but have been self taught for much longer. I'm only just starting college and I'm already angry.

What does a college degree really mean anymore? From some of the posts I've seen on devRant, it certainly doesn't ensure professional conduct, work ethic, or quality (shout out to the brave souls who deal with the lack of these daily). Companies should hire based on talent, not on a degree. Universities should focus more on real world applications or at least offer such programs for students interested in entering the workforce rather than research positions. A sizable chunk of universities' income (in the U.S. at least) comes from research and corporate sponsorships, and educating students is secondary to that. Nowadays education is treated as a business instead of a tool to create value in the world. That's what I signed up for, anyway - gaining the knowledge to create value in the world. And yet I along with many others feel so restricted, so bogged down with requirements, fees, shitty professors, and shitty university resources. There is so much knowledge out there that can be put to instant practical use - I am constantly shocked at the things left out of my college curriculum (lack of automated tests, version control, inadequate or inaccurate coverage of design patterns and philosophies) - things that are ABSOLUTELY essential to be successful in this career path.

It's wonderful that we eventually find the resources we need, or the motivation to develop essential skills, but it's sad that so many students in university lack proper direction through no fault of their own.

Fuck you, universities, for being so inflexible and consistently failing to serve your basic purpose - one of if not the most important purpose on this earth.

Fuck you, corporations, for hiring and paying based on degree. Fuck you, management, for being so ignorant about the industry you work in.

Fuck you, clients, who treat intelligent people like dirt, make unreasonable demands, pull some really shady shit, and perpetuate a damaging stereotype.

And fuck you to the developer who wrote my company's antipattern-filled, stringy-as-all hell codebase without comments. Just. Fuck you.

I think my automated test texts me more often than my boyfriend does

Dev manager: great news guys. We’ve built a new tool to do automated testing on apps. We’ve gotten rid of the old Appium solution we were using and built this new one.

Me: why not just use the inbuilt native stuff? Click to record works really well.

Manager: nah we thought it would be more flexible to build it ourself.

Me: ... ok ... moving on ... how does it work?

Manager: well this new .jar, you download it, pass in a config file, setup up your simulator and appium and the jar will do everything for you.

Me: ... wait you said you hate Appium? Now you’ve built a wrapper around it? And it doesn’t even set everything up, you’ve to do it all by hand?

Manager: oh we had too, would be too much effort to replace it. Don’t worry we can now write all our tests in .yaml config files instead of using Appium.

Me: so we’ve lost the ability of auto-complete and type ahead, everyone has to upskill on a new tool, it offers no new features over what’s available out of the box and we’ll have to deal with new bugs and maintenance and stuff our self ... because we need more flexibility?

Manager: oh don’t worry. The guy who built it is staying here. He’s going to deal with bug fixes and add features. He’s only one guy, but he’s really sharp, it’ll be great for us and the team.

Me: ... ... ...

*audible noise of soul breaking*

Me: ... ok thank you. I’ll look into this new tool

No boss... For the fucking millionth time: unit tests are not a waste of time.

You keep testing everything manually and hoping that you tested everything every time and praying that there are no bugs IS THE FUCKING TIME WASTE

My boss just can't fucking wrap his head around automated tests... I'm trying hard... Gonna try harder...

Normally I just read rants but my new assignments is just to much and I have to vent a bit.

So I was assigned on a new company to help them with their automated tests (I'm normally a developer) which was fine for me. Especially when they said a guy that have 10+ years of experience have worked on the framework for a couple of weeks so it should be fine and ready. So I though it would be a quick deal.

But then I got there and... it's the worst C# code I have ever seen. I can live with the overuse of static, long method and classes and overally messy classes that doesn't really seems to fit (it's bad but not unusual in test code it seems). My biggest problem is overuse of the damn "dynamic" keyword.

Don't get me wrong, dynamic can be good and it have it's uses but here they use "dynamic args" in every single method, every one! They don't care if the method only require one value or ten values, they use dynamic args. Then you follow this "dynamic args" parameter going in to sub method after sub method and you have no idea what they use.

And of course they don't know if anyone use the methods correctly (as you have no damn clue what to use without checking the source code) so in 75% of the methods they convert the dynamic to an object and check if it contains "correct argument".

So what I have here is a code that isn't just hard to use, it's a hell to maintain.

So I talked with this with other testers on the team and they agree, but as most of them lack experience they couldn't talk back to the senior that wrote it. So I hope to sit down with him this week and talk this through because it would be fun to hear the arguments for this mess.

/rant

I got a call at 12:30 one night a few months back. Apparently some back-end scripts I edited to fix an automated test setup crashed around 75 test pc's and halted somewhere around 2000 tests. I quickly jumped on, fixed the issue, and got everything back online.

I was up all night certain I would get fired. First thing in the morning the client says welcome to the club some, of the best have done the same thing.

The company i work for has a jenkins server (for people that don't know jenkins, it's an automated build service that gets the latest git updates, pulls them and then builds, tests and deploys it)

Because it builds the software, people were scared to update it so we were running version 1.x for a long time, even when an exploit was found... Ooh boy did they learn from that...

The jenkins server had a hidden crypto miner running for about 5 days...

I don't know why we don't have detectors for that stuff... (like cpu load being high for 15 minutes)

I even tried to strengthen our security... You know basic stuff LIKE NOT SAVING PASSWORDS TO A GOOGLE SPREADSHEET! 😠

But they shoved it asside because they didn't have time... I tried multiple times but in the end i just gave up...

Today I fell down the rabbit hole.

I've been writing some automated tests which found an asymmetry in our algorithm which I think is caused by an off by 1 in even input dimensions.

Change input to odd dimensions, crash due to out of bounds exception.

Switch to debug mode to try to work out why we crash, failing asserts for default function arguments with no obvious reason beyond a helpful message saying they're unsupported.

"No time for automated tests, we've got too much testing to do..."

I think I want to quit my first applicantion developer job 6 months in because of just how bad the code and deployment and.. Just everything, is.

I'm a C#/.net developer. Currently I'm working on some asp.net and sql stuff for this company.

We have no code standards. Our project manager is somewhere between useless and determinental. Our clients are unreasonable (its the government, so im a bit stifled on what I can say.) and expect absurd things from us. We have 0 automated tests and before I arrived all our infrastructure wasn't correct to our documentation... And we barely had any documentation to begin with.

The code is another horror story. It's out sourced C# asp.net, js and SQL code.. And to very bad programmers in India, no offense to the good ones, I know you exist. Its all spagheti. And half of it isn't spelled correctly.

We have a single, massive constant class that probably has over 2000 constants, I don't care to count. Our SQL projects are a mess with tons of quick fix scripts to run pre and post publishing. Our folder structure makes no sense (We have root/js and root/js1 to make you cringe.) our javascript is majoritly on the asp.net pages themselves inline, so we don't even have minification most of the time.

It's... God awful. The result of a billion and one quick fixes that nobody documented. The configuration alone has to have the same value put multiple times. And now our senior developer is getting the outsourced department to work on moving every SINGLE NORMAL STRING INTO THE DATABASE. That's right. Rather then putting them into some local resource file or anything sane, our website will now be drawing every single standard string from the database. Our SENIOR DEVELOPER thinks this is a good idea. I don't need to go into detail about how slow this is. Want to do it on boot? Fine. But they do it every time the page loads. It's absurd.

Our sql database design is an absolute atrocity. You have to join several tables together just to get anything done. Half of our SP's are failing all the time because nobody really understands the design. Its gloriously awful its like.. The epitome of failed database designs.

But rather then taking a step back and dealing with all the issues, we keep adding new features and other ones get left in the dust. Hell, we don't even have complete browser support yet. There were things on the website that were still running SILVERLIGHT. In 2019. I don't even know how to feel about it.

I brought up our insane technical debt to our PM who told me that we don't have time to worry about things like technical debt. They also wouldn't spend the time to teach me anything, saying they would rather outsource everything then take the time to teach me. So i did. I learned a huge chunk of it myself.

But calling this a developer job was a sick, twisted joke. All our lives revolve around bugnet. Our work is our BN's. So every issue the client emails about becomes BN's. I haven't developed anything. All I've done is clean up others mess.

Except for the one time they did have me develop something. And I did it right and took my time. And then they told me it took too long, forced me to release before it was ready, even though I had never worked on what I was doing before. And it worked. I did it.

They then told me it likely wouldn't even be used anyway. I wasn't very happy at all.

I then discovered quickly the horrors of wanting to make changes on production. In order to make changes to it, we have to... Get this

Write a huge document explaining why. Not to our management. To the customer. The customer wants us to 'request' to fix our application.

I feel like I am literally against a wall. A huge massive wall. I can't get constent from my PM to fix the shitty code they have as a result of outsourcing. I can't make changes without the customer asking why I would work on something that doesn't add something new for them. And I can't ask for any sort of help, and half of the people I have to ask help from don't even speak english very well so it makes it double hard to understand anything.

But what can I do? If I leave my job it leaves a lasting stain on my record that I am unsure if I can shake off.

... Well, thats my tl;dr rant. Im a junior, so maybe idk what the hell im talking about.

Boss coding.
Boss not fan of tests at all.

"Hey I'm doing all of tests" - boss to me.
"Cool, are they automated? Or do you want me to implement'em?" - me to him

[long speech about why tests are irrelevant including "...once I tested, it is tested, we dont need to have automated tests."] *im teaching you because you dont know voice*

Please, help meeee

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

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

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

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

I'm a jr developer. I started off in automation testing and don't mind it but the testing codebase is cancer, doesn't follow basic Java conventions even basic naming conventions like camelcase, and the tests are super slow using hardcoded Thread.sleep(). Since the automation tests are not automated, I have to run manually. YES manually, every morning I wake up early at 7am to run the 2.5 hour long tests (7am because this before people get to work and when the application goes back online). I run this bitch and monitor them but most of them fail anyways. I also have to write a email report on the results which means I have to explain why shit is failing so I have to debug all this crap. This shit literally eats up an additional 2-3 hours of my work day everyday and the time is not even accounted for. ALSO, since it's running on my laptop, it makes my computer slow most of the day. If I have to debug, I can't have the browser be headless so fuckin chrome browsers be popping up every 2 minutes. I did this for legitimately 8 sprints until I decided enough was enough and bitched about it and the team told me I had no choice. I eventually got them to push towards automating it but it's still in progress so I'm still running this dumb shit. The contractors try to take advantage of me any way they can by giving me mindless bitch work they don't want and they know I don't usually say no since I'm a jr resource. I hate running the fucking automation tumor. Sometimes I go into the meeting rooms alone to scream.
I feel like I'm wasting my life away and not learning as much as I could somewhere else

Oh, my boss never fails to amaze me...

Every fucking time he talks about changes to someone outside the team he says something like:
"we always gotta be prepared for breaks because it is always like that, you change something here and when you see you broke something there"
All in a manner that *tries* to bring tensions down.

And every time I explain to him why the fuck automated tests are important and wtf they do he always manage to understand it as a waste of time...

I'm never gonna give up, motherfucker.

Once upon a time, one or two jobs ago, a really awesome engineer specced out a distributed search application in response to a business need. This company was managed pretty oldschool and required a ton of paperwork and approvals.

The engineer spent many weeks running tests and optimizing the hell out of this app cluster. It flew, and he had the data to prove it could handle production workloads (think hundreds of terabytes of data being processed every single day)

Part of the way he achieved this was having RAID0 on all of the servers to maximize I/O throughput. He didn't care much about data loss, since the application itself was fault tolerant on a much more granular level.

Management, hearing about this, absolutely flipped their shit and demanded RAID6 instead. This despite the conclusive data that the engineer had that proved RAID6 couldn't keep up.

He more or less got told to STFU.

Even this despite the fact that a RAID restripe would actually take many times longer than rebuilding the failed node from scratch (a process that took about 30 minutes by hand, and could probably be automated to be done in less than five), causing a longer exposure to actual data loss throughout the length of the days-long array rebuild time.

The ill-thought-out requirement added about 50% to the cost of the project (*many* more hard drives now required), beyond the original budget, and the subsequent bureaucratic wrangling resulted in a late product launch.

6 months or so later, after real customers were using this product, the app was buckling under around half of its expected workload. A friend of the engineer suggested to management to try RAID0. Sure enough, that resolved the I/O bottleneck.

This rage-inducing story has a happy ending, though! Said engineer left the company not long after this incident, citing it as a reason for his departure. He was immediately hired by another company, making integer multiples of his prior salary.

The product the company botched the launch of by ignoring his spec? It died a few months later. Maybe the poor customer experience was to blame? Maybe the late launch? Maybe it was another reason entirely.

Either way, millions of dollars of hardware now sat fallow. This was a black eye on the company all the way up to the C-level.

tl;dr: Listen to your engineers. You hired them for their expertise.

Yeah, hiring people solely to write unit tests is a completely reasonable thing to do, i mean, its not like unit tests are a perfectly repetitive task that could easily be automated or anything...

Starting to feel like shit about my new job. Every task my boss gives me I return with a "sorry it can't be done" for one reason or another. At first it was because user interface testing is a nightmare, then it was because the API postman tests he wanted is for endpoints we haven't exposed so it can't be done and the automated login on postman and retrieval of cookie information can't be done through postman because it requires rendering the site in a browser. I feel worthless to the company but I also feel he keeps making up tasks for me without checking if they're actually useful to us or even possible first, rather than let me touch any of the real code.. I don't know if I should just quit tbh.

Our project at work goes live in 3 weeks.

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

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

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

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

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

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

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

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

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

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

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

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

No one there understands css properly. Or javascript.

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

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

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

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

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

I know I'm writing the correct integration tests when each one I add uncovers a new bug.

Still, it would be nice if just one of them passed first time.

Blue Robotics

This company makes underwater thrusters for submarine applications. With their first thruster they made it easy to make a homemade submarine. The motor was powerful, the thruster just worked. They even had a promotional where they created an automated surfboard that made it from hawaii to somewhere in california with one of their thrusters pushing it there the entire way. It was a great product.

Then they created the next version. This was the same thruster, but it had an ESC(Electronic Speed Controller) sealed in an aluminum puck on top of the motor. This ESC could be controlled by servo controls, or by plugging it into an i2c bus. You could pull different stats off of the motor over i2c it sounded great. So my robotics team trusted this company and bought 8 motors at $220 - $250 bucks each. We lightly tested them since we had not even finished the robot yet. One week before the competition our robot got completely put together and we did our first few tests.

Long story short, Us and 22 other teams did roughly the same thing. We bought these motors expecting them to work, but instead the potted aluminum ESCs were found defective. Water somehow got into the completely resin sealed aluminum puck and destroyed the ESC. We didn't qualify that year due to trusting a competition sponsor to deliver a good product. I will admit that it was our fault for not testing them before going to the competition. Lessons were learned and an inherent distrust of every product I come across was developed.

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

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

To what I replied:

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

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

My tech debt meltdown is happening right now. We are releasing our huge micro service based product next week with no automated testing of any sort. Our front end clients are relatively DRY. No tests and dry = can't change anything = hacks on top of hacks.

Why? Team lead won't listen to me and has beaten me down so I don't care anymore. If it's broken fuck it.

Had some fun running automated UI tests today.

Background: My project is a cloud based tool for running automated tests against a 3rd party SaaS product, so when you start a test run, it opens a Firefox window and runs some selenium automation against the 3rd party product.

Our UI tests also open a Firefox window to log into our local env and run some selenium.

Today I tried to run 4 of our UI tests in parallel.

So each test case creates a Firefox instance, and each of those starts a test run which creates another Firefox instance, sometimes 2, depending on the process being tested.

In short, at one point I had 11 different Firefox windows open, all running selenium automation.

My laptop sounded like it was trying to take off...

This week at work I spent 20 hours debugging automated tests to avoid manual testing that would've taken a few hours.

In hindsight, this was entirely predictable

I love git stash.

It's helps a lot for doing refactors to me. I guess it's not the most complex workflow, but it wasn't obvious to me when I started with git. Let me explain.

Refactors. As you start writing the first lines of a refactor, you start to notice something: you're changing too many things, your next commit is going to be huge.

That tends to be the very nature of refactors, they usually affect different parts of code.

So, there you are, with a shitload changes, and you figure "hey, I have a better idea, let me first do a smaller cohesive commit (let's call it subcommit) that changes a smaller specific thing, and then I'll continue with the upper parts of the refactor".

Good idea, but you have a shitload of changes nearly touching every file in your working copy, what do you do with these changes? You git stash them.

Let's say you stash and try to do that smaller "subcommit". What sometimes happens to me at this point is that I notice that I could do an even smaller change inside this current "subcommit". So I do the same thing, I git stash and I work on that even smaller thing.

At some point I end up `git stash pop`ing up all these levels. And it it shows that git stash is powerful for this.

* You never lose a single bit of work you did.
* Every commit is clean.
* After every commit you can run tests (automated or manual) to see shit is still working.
* If you don't like some changes that you had git stashed, you can just erase them with git reset --hard.
* If a change overlaps between a stash you're applying and the last "subcommit", then
if they differ, git shows conflicts on the files,
if they are identical, nothing happens.

with this workflow things just flow and you don't need to wipe out all your changes when doing simpler things,
and you don't need to go around creating new branches with temp commits (which results in bloated temp commits and the work of switching branches).

After you finish the refactor, you can decide to squash things with git rebase.

(Note: I don't use git stash pop, because it annoys the fuck out of me when I pop and you I get conflicts, I rather apply and drop)

Hennies I need your assistance!
My boss has put me in charge (wow yes I was surprised too) of figuring out what a good solution to our current testing nightmare would be. Therefore my questions for you are:

What kind of testing strategy do you work with at your job? Do you use any tools for it? How's the division of unit tests/service tests and/or UI tests?

I'd really appreciate you guys' input on what works (and what doesn't, in case you're living a nightmare with testing daily)

Wouldn't call it a software bug but related:

Was developing an order system to expand in the UK. We have been developing it for the last 2 years and always had a one nasty bug in the system... Whatever we do, it still appears... Tried debugging to find the source, tried covering with tests - nothing helped it was still there. We even rewrote the whole system 3 times and it still was there!

One day, we have been given a stupid request from our manager - take a black background and make it even more blacker... That was it and I went to the CEO with letter where I stated that we should remove the manager... As I'm the Senior there, he did ask me why and eventually removed the manager...

Oh my guys, I've never felt so good after removing a bug! Since then - our application went live, we had our first customers and we were happily rolling new updates. And the best part - there was no BUG! Everything we did just had undocumented features or missing links but we haven't really had a single bug that was not caught by our automated tests!

---

Moral of the story:
Not only software can have bugs. People also can be "bugs" while bugging you about every single details they think is not working correctly.

The feeling when your scrum master or lead ask you run the automated tests against the application though they know the application is down or not working.

The moment when you have crafted a beautiful, flexible and well structured package.
Everything including the automated tests are flawless..

but you cant help but feel like something, somewhere is horrible wrong... :D

After 3 months of working at my current and first job I inherited a spaghetti codebase with files as large as 1000 lines because my mentor left.
Everything works but dare to change a thing. No Unit tests or any sane practices. At least our CI/CD is automated. 😂

Now I am asked to bend the library backwards in order to integrate it with another product. No one helps me and I am slowly starting to feel devastated. 😩

Some of my co-workers are so fucking dumb. Their thought process....

Let's re-run tests that are currently failing over and over until it works

😡

like bitch....fix it then run it! don't just run shit over and over to make yourself look busy.

After building some automated regression tests to verify parts of the company website were working, it was discovered that a test case was missing.
Instead of a constructive meeting about fixing the issue and adding a test, I was reamed and my manager was reamed that we "missed this case".
Nevermind that the automation caught several issues before release in nearly every other aspect of coverage.
Nevermind that the missing test case was a useless feature added after the automation was completed.
Nevermind that automation was meant to be the last stop in the gate, not the first...

I was so livid after that meeting I nearly resigned on the spot. My manager was so livid over being told to write me up he was ready to resign.

That feel when your job's codebase is well-maintained, extensively covered with unit, integration and full product automated tests, everything is run through continuous integration, and every change has to be scrutinized and reviewed by multiple people; so you have barely anything to devRant about :(

this really happened:
Interface Team Lead: "hey I want any time deployments and better QA"

Me: "ok sure. I have CI/CD, but yiu need to work in feature branches / tags, and make sure your code passes automated builds and unit tests"

Team Lead: "I dont have time to test it makes me unproductive! and creating a branch is an extra step which is going to set me back. Im telling the boss you are impacting performance!"

Me: "you want better deployments and QA, but you can even create a branch or tes your work?"

Team Lead: "We have deadlines!"

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

A day in the life of @C0D4

Yay it's Tuesday.....

So morning goes something like coffee, yea no coffee no @C0D4, get to the office, get busy with normal morning routine - run the almost automated scripts I have to run - delete the 100+ emails I don't actually need from last night, read the 2 I do care about - yea 2 freakin emails out of 117 🤦‍♂️
But what ever that's what outlook rules are for... except I actually have to glimpse over them all just in case something of mine broke.

Go get another coffee,
Start working through the days tickets - ok cool nothing major to worry about, let's get back to writing tests from yesterday.

Well fuck that was a bad decision, no matter what I do this little fucker won't pass, yet doing this process step by step, detail for detail, it works - no issues, but automate this fucker and it screams its head off.

So fine, I give up and go to lunch,
Come back... spend next 3 hours on this 1 problem... 1 FREAKING problem 🤦‍♂️🥴🤦‍♂️🥴🤦‍♂️

This thing has beaten me, and for no apparent reason - it just doesn't like running under a test scenario.
Would have given up hours ago, except its a vital piece of code I'm trying to cover 😑 of course it is.

Well somewhere in there I managed to do a deployment for another project and change a few things in there.

This week is starting to look like hell,
Yay hump day tomorrow!!!!!
That's something, the week is coming to an end.... right? Please.... right!!!

We are all about structures, clean code and many other things that make our life easier, right?

Well... It's not all white and black...

As talked many times, projects can be rushed... Client budgets can be low at the start and only then grow...

Let me take an example:

Client X needs a tool that helps his team perform jobs faster. They have a $500 budget. So... Testing, clean architecture and so on - are not really a viable option. Instead, you just make it work and perform that task as needed. So the code has minimal patterns, minimal code structure, a lot of repetitive parts and so on.

Now... Imagine that 3 months pass by without any notice and clients are ultra happy with the product. They want more things to be automated. They contact developers and ask for more things. This time they have a bigger budget but short timeframe.

So once again, you ignore all tests, structure and just make it work. No matter what. The client is happy again.

A year passes and the client realizes that their workflow changed. The app needs total refactoring. The previous developer has no time for adjustments at this point and hires a new company. They look at the code and rants spill out of their mouth along with suicidal thoughts.

So... What would you do? Would you rant about "messy project" or just fix it? Especially since people now have a bigger budget and timeframe to adapt to changes.

Would you be pissed on such a project?
Would you flame on previous devs?
Would you blame anyone for the mess?

Or would you simply get in and get the job done since the client has a "prototype" and needs a better version of it?

---

Personally, I've been in this situation A LOT. And I'm both, the old and new dev. I've built tons of crappy software to make things work for clients and after years - they come back for changes/new things. You just swallow the pill and do what is needed. Why? Well, because it's an internal system and not used by anyone outside their office. Even if it's used outside the office - prototyping is the key. They didn't know if the idea would work or be helpful in any way. Now they know and want it done correctly.

Crazy deadlines> Director: "You need to design a new architecture that has failover, multi-AZ, automated deployments, CI/CD pipeline, automated builds/tests as well, for our new SaaS product. You have 3 days to complete it"

Me: "Ok cool. Do we have the new product developed? Can I have the spec docs of the new software, libs and packages required for the env?"

Product Lead: "No we dont have anything yet. The POC is on my local PC, but I dont know what packages are needed to run it"

Me: "So I cant design anything unless I have the minimum requirements to run the new software"

Director: "Just get it up and running in a live environment and we'll take it from there"

Me: *sigh*..this is going to be a big mistake

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

The time that I felt most like a Dev badass was when I had introduced an E2E test framework and added a bunch of helper classes to it so that our QA team could pick it up and write automated tests for the manual tests they had been doing for years.

Sure, the whole department got laid off after that because we had gotten a new CTO and all of my work was essentially for naught, but it made a lot of people enjoy showing up to work for the first time in a long time, and that was what mattered most to me

Started working as a "working student" in an it company to write unit tests. (which then will be executed automatically - so automated unit tests)

Realised that I write more or less the same code just changing the names and some parameters (sometimes more if it's not an number but a bool for example but it's pretty much the same scheme)

So I bought a tool for 1$ to use "auto complete" on custom templates.(I type testgetbool and the tool replaces this to the test case only asking for the variable name.)

So now I'm writing automated automated tests 😁😅

(which is btw pretty boring but cost & time effective)

I recently started to use automated tests for everything and it is really great to not worry about every little change anymore.
But I think I'm not very good at it. The tests themselves are quite slow and I'm not sure if I'm covering everything the right way. Also, I'm very slow at writing the test cases.
SO I want to learn more about it. Do you have any recommended books on this topic? Anything about unit or feature tests and TDD, language specific (PHP) or general is appreciated

This is why we can never have enough software developers

It's true. No matter how many people learn to program, there will never be enough people who know how to program. They don't have to be very good at it either. It is now a required skill.

Minimum wage in first world countries is way above 5$ per hour. A Raspberry PI 3B costs 40$, or at most 1 day of work for the worst paid jobs. And it will run for years, and do routine tasks up to thousands of times faster than any employee. With that, the only excuse that people still do routine tasks, is the inaccessibility of coder time.

Solution: everybody should know how to write code, even at the simplest level.

Blue-collar jobs: they will be obsolete. Many of them already are. The rest are waiting for their turn.

Marketing people - marketing is online. They need to know how to set up proper tracking in JS, how to get atomic data in some form of SQL, how to script some automated adjustments via APIs for ad budgets, etc. Right now they're asking for developers to do that. If they learn to do that, they'll be an independent, valued asset. Employers WILL ask for this as a bonus.
Project Managers - to manage developers, they need to know what they do. They need to know code, they have to know their way around repositories.
QA staff - scripted tests are the best, most efficient tests.
Finance - dropping Excel in favor of R with Markdown, Jupyter Notebooks or whatever, is much more efficient. Customizing / integrating their ERP with external systems is also something they could do if they knew how to code.

Operations / Category Management - most of it would go obsolete with more companies adopting APIs as a way to exchange important information, rather than phone calls and e-mails.

Who would not be replaced or who wouldn't benefit from programming? Innovative artists.

A lot of it might not be now now, but the current generation will see it already in their career.

If we educate people today, without advanced computer skills and some coding, then we are educating future deadbeats.

With all this, all education should include CS. And not just as a mandatory field or something. Make it more accessible, more interesting, more superficial if needed. Go straight to use cases, show its effectiveness in the easiest way possible. Inquisitive minds will fill in the blanks, and everyone else will at least know how to automate a part of their work.

Client and ex-Dev/manager wanted automated testing.... manager doesn't see a reason for interfaces... Still wants unit tests, and a SOLID design. Doesn't want to pay for the extra time needed. Good times

"Don't write bad code." when asked about adding automated tests.

As I'm on a research/algorithm improvement project at work I'm working pretty much independently. As such I've set up an automated test framework and writing tests for any piece of code I touch.

Today as I was fixing a bug in production area I was demoing my tests to CTO and principal design engineer. They come from a hardware background and have pushed back against automated tests in the past but they were interested in what I was doing.

I WILL DRAG THEM KICKING AND FUCKING SCREAMING INTO THE WORLD OF AUTOMATED TESTS.

I don't get the bug "joke" that's flying around. If you have 99 bugs and fix one, why would you have more? Do you not have automated tests?

Currently in our 4th cycle of manual regression testing for a release and still finding bugs. Automated tests? What are those? That sounds an awful lot like it would take time to implement. Time that could be spent fixing the bugs and getting the release out the door.
When release dates take priority over quality....

Just joined a new company and can only describe the merge process as madness.....is it or am I the one that is mad?!

They have the following branches:

UAT#_Development branch
UAT#_Branch (this kicks of a build to a machine named UAT#)

Each developer has a branch with the # being a number 1 to 6 except 5 which has been reserved for UAT_Testing branch.

They are working on a massive monolith (73 projects), it has direct references to projects with no nuget packages. To build the solution requires building other solutions in a particular order, in short a total fucking mess.

Developer workflow:

Branch from master with a feature or hotfix branch

Make commits to said branch and test manually as there are no automated tests

Push the commits to their UAT#_Development branch, this branch isn't recreated each time and may have differences to all the other UAT#_Development branches.

Once happy create a pull request to merge from UAT#_Development to UAT#_Branch you can approve your own pull request, this kicks off a build and pushes it to a server that is named UAT#.

Developer reviews changes on the UAT# server.

QA team create a UAT/year/month/day branch. Then tell developers to merge their UAT#_branch branches in to the previously created branch, this has to be done in order and that is done through a flurry of emails.

Once all merges are in it then gets pushed to a UAT_Testing branch which kicks off a build, again not a single automated test, and is manually tested by the QA team. If happy they create a release branch named Release/year/month/day and push the changes into it.

A pull request from the release branch is then made to pre-live environment where upon merge a build is kicked off. If that passes testing then a pull request to live is created and the code goes out into production.

Ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh it's a total mess. I knew when I took on this job it would be a challenge but nothing has prepped me for the scale of the challenge!! My last place it was trunk based development, commit straight to master, build kicks off with automated testing and that just gets pushed through each of the environments, so easy, so simple!

They tell me this all came about because they previously used EntityFramework EDMX models for the database and it caused merge hell.

Our systems lead is trying to tell our software person how much adding unit tests would cost. It also sounds like he wants TDD to be added in after the fact. And he's bitching because the software guy won't move forward with it until we get it with the customer. He also wants all of them automated, but doesn't want to accept that that is going to cost a lot. Like a lot, a lot. This is a guy who doesn't know algorithms (had to explain dykstra to him), doesn't understand the tech stack we are using (I had to explain .net versions, the JIT compiler, and garbage collection to him), and seems not to understand hardware (I had to explain floating point math to him), yet he feels qualified to tell us how long it is going to take us to implement automated unit tests for major, complex features.

when it takes more effort to writing a bunch of dumbass mocks and stubs so you can have an automated test, than it does to manually test, because you're too retarded to figure out how the fuck easymock is supposed to work, and being awful at your job, also fuck java imports and easymock for being difficult to work with

shout out to my coworkers for requesting more automated tests

can't wait till it all gets deleted anyway because we're going to delete the code we're testing

Honest question:. Why do people worry so much about following OO principles? The basics I understand - things like accessing child classes through parent objects. Others, I don't really get.

I write automated tests, and call a method to configure certain documents using db inserts every time. Why shouldn't I be able to override that on a per spec basis, especially when the class that handles the insert isn't a child of the setup classes in the first place?

when you're the unlucky fuck and/or too stupid to get green builds so you get flamed when the flaky automated tests (from before your time, not written by you) rear their head and shit all over you

you then get flamed for not going out of your way for fixing them, as the team verbally agreed to do so, but very rarely if at all has anybody done so (it's not so easy trying to fix something when you don't have consistent steps to reproduce)

I think maybe I am doing something wrong.

I have this node.js application I am building with typescript and I wrote tests in mocha. Now I need to make some changes which break quite a few tests.

When I run mocha on the command line the errors whizz past. When I worked in java and .net (with junit and nunit) you could just click a test in the ide to run it. So you could 'fix' one test at a time. Also you could just double click on a fail and it would jump you to the code for that test or the exception that failed.

I found this extension for visual studio code that adds a sidebar to visual studio code. It looked good but now I spent the last hour trying to get it to run typescript tests - looks like it doesn't support the compilers argument.

Surely other developers must do this sort of stuff. I am not using an obscure technology stack right? Do you write automated tests for your codebase? What tools do you use? Should I switch ide? switch testing frameworks?

R&D Lead Architect: "We want this next gen platform to be all AWS."
Us: "Alright, can we talk about automated testing?"
R&D Lead Architect: "Sure, for automated tests you'll want to just dump events from your system into a flat file on S3. It's readable with Microsoft Excel."
Us now: still here.
R&D Lead Architect now: not here.

:)

Does anyone here work with automated acceptance tests? I don't know a lot about them and I've been wondering if it's too time consuming to write them and if it's better to test manually

Funny how things comes around...
So... project start-up... everybody learning and designing the future new system. Then we get to a point that we saw that we'll probably need someone outside or dev team to setup all the environments CI/CD pipelines... Our PM said "what about we get a Devops guys to take care of that?" Most of our team members agreed but our Techlead said "Devops is not a job, it's a culture.". Ok, nice... I understand that point, but for a system of the size of the one that we're building...It would probably be a good idea to have someone to take care of that for us. BUT, he (the techlead) said that he will be taking care of all that himself (along with coding part of the backend).

RESULT: We're stuck in the point that we're unable to test our system in the correct environment, we've no pipeline for automated deploy of our sprints...

Guys, I think the Devops is no more then somebody that is going to take care of some tasks in the project, like the backend, the frontend, the tests, the management...

Skipping jasmine tests- especially ones on partials (not the controller). Seriously, QA has automated test suites to test UI functionality. If it takes 30 mins to write the code and 3 hours to write the tests... it may just not be worth the effort when there already is automated testing.

Ugh I hate skipping them but you know how to test the UI? Use the UI.

Pushing Changes without running the automated tests on my local machine.

Me, taking a coding class in uni:
Purposely cramping everything in as few lines as possible, making the code barely readable, just to screw with the guy who had to correct this mess.
In my defence, the assignment they gave us was garbage. The task descriptions were often ambiguous or even contradictory to what actually was the case ("The InputStream will contain a string of csv data, each element starts in the next line" -> was a malformed single line string) and the automated tests they wrote to check our output where either completely unhelpful because of their meaningless error messages, or sometimes even plain wrong, telling us our output was wrong, even though it definitely wasn't.

I dislike qa's but I hate automated tests more

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

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

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

Just wondering any of you has seen automated tests in a CI machine? Theyre not reliable enough to be running all the time because many times its just an empty error amd its tedious to investigate and wastes lots of time

New version, new regression tests. It's the first time I'm trying to run them fully automated. Tests were ok separately, but as it turns out, "random" generated number is not OK for creating unique names if it's being created from datetime (yymmddmmss), and tests run within one minute.
Also, new version broke our hack of disabling browser pop-up confirmations. Fuck.

When you're working with a QA/test engineer that insists on manually testing code that have automated tests. Can any test engineera chime in here?

I'll be learning how to build automated integration tests for a serverless infrastructure during the Superb Owl tomorrow. How about you?