Are you familiar with neocities (geocities revival thing)? It's not anti-scripting but it may scratch your itch.

We ~~have~~used to have a scrum master so we're already agile! /s

They want those things, sure, but I think it would take multiple weeks of dedicated work for me to set up tests on our primary system that would cover much of anything. Big investment that might enable faster future development is what I find hard to sell. I am already seen as the "automated testing guy" on my (separate) project, and it doesn't really look like I'm that much faster than anyone else.

What I've been meaning to do is start underloading my own sprint items by a day or two and try to set up some test infrastructure in my spare Fridays to show some practical use. But boy is that a hard thing to actually hold myself to.

especially if the code has been written in a way that makes it difficult to write a robust test.

I definitely deserve a lot of blame for designing my primary project in making hard to test. So, word to the wise (though it doesn't take a genius to figure this out), don't tell two fresh grads and a 1 YoE junior to "break the legacy app into microservices" with minimal oversight. If I did things again, I still think the only sane decision would be to cancel the project as soon as possible. x.x

I actually was using a mock webserver with the expected request/response, which sounds like what you're getting at. Still felt fiddly though and doesn't solve the huge mock data problem which is more an architecture design failing.

I've mostly gotten away from testing huge methods with a seemingly arbitrary numbers in favor of testing small methods with slightly less arbitrary numbers, which feels like a pretty big improvement.

How are you gonna get good at it if you don’t do it! :D

True. :)

This is a bigger problem than tests.

You mean things going over estimates or SM/EM complaining about it?

You’re presenting a solution for a problem that the team either does not see as important or doesn’t think exists at all.

Definitely it's a known issue, and I think people think it's semi-important. Feels like every other standup has a spiel from the EM about "we need to test things, stop breaking things, etc.".

Whenever I argue on their terms though, I quickly "lose", because business terms seem to be, "agree to everything from the business, look busy, and we will have time for IT concerns (i.e., testing) when we are done with business projects for the year (i.e., never)."

If I want any meaningful change, I think it will need to be be something I work around management on.

I guess since we have manual QAs, there's less motivation to get away from manual testing as it's literally their job description. Not to say we aren't wasting time and money still. I do find other devs and I still need to spend a lot of time ourselves manually sanity checking things.

That all does sound like my dream end goal, though, thanks for the responses.

Nah, red flag is certainly accurate in my case.

We really don't have a strong hierarchy of engineering leaders. Devs are all pretty much equal. EM is extremely hands-off, but also prefers to hire inexperienced developers to "train them up" (which seem like contradictory ideas...). So we we have a very free-for-all development process after work is assigned. And of course very few (zero?) devs really want to start doubling estimates for quality that no one seems to care strongly about.

(The saving grace here, if you can call it that, is that it's very easy to go around leadership and do whatever you want with the dev process, so long as you can do it yourself. So perhaps what I should do is add stricter code coverage checks on the services primarily worked by me as a way to protect me from myself, and maybe convince some others to join in.)

My project fits both. It took about a year before this was shown to more than a couple business users. But we still had Scrum sprints and pressure to get items done at the sprint, even with no deployment or demo for feedback.

We are reasonably consistent with estimates, but there's this hidden assumption that 1 point equals 1 developer day. So even though we consistently get 20-25 points done per sprint, we typically cram more items to meet that 30 point threshold.

Oh, and of course you may end up dragging items sprint to sprint if they don't get finished.