Unit testing. At least unit testing.
I thought this was a solved problem, people. Agile has come out of the shadows and dominated the techie buzzword machine for years now. Everyone is doing Scrum now, right?
Well, OK, they're usually doing "ScrumBut". "We're doing Scrum, but we're not demoing our software to the customer." Or, "We're doing Scrum, BUT we're not doing the team code ownership thing." Usually, it just means that some of the team gathers on a semi-regular basis to do a "standup". But that's a rant for another time.
Unit testing. Why are we still not writing tests? I was invited by a US state a couple years ago to review some software for which they were getting ready to shell out a substantial sum of money. They wanted to know if the code was worth the dough. They owned the code - but there was not a single unit test in all of the 200K+ lines of code for the product. When we presented our findings, the lack of tests, which could assure the customer that the code was executing according to the requirements, was a primary factor in their rejection of the product.
Another customer asked us to assist them in migrating several dozen apps from on-premises to Azure. We went through dozens of interviews and not one of those apps had unit testing. Each interview sounded the same type of refrain, "We're going to start testing soon." "That's something we're working on." "We know that we haven't done the best job with testing." If they are to take advantage of the DevOps scenarios we're proposing, they'll need to be assured that their software is performing the way they think it should be (eg. it's tested) before they can even consider DevOps.
We all see the benefits of testing, right? Are we lazy? Are we pressured by management to "just build features" and "no time for testing"? Unless you just don't care if your code works, that's got to cause all sorts of anxiety. Sometimes this happens, though, even at Microsoft Consulting Services. Several months ago I was asked to review one of our projects that was experiencing... "customer dissatisfaction", let's say. No tests. Even at MCS? We have our own Playbook that stresses the importance of testing, and that if testing is not supported by the project or customer, it is reason to walk away from that customer.
Got tests? Ah, I can finally sleep at night. Peace. Assurance - and dare I say, "rigor"?
I've been doing this agile thing for about 14 years now. I watch trends, I practice the craft - and doing so has its momentum. I admit, I am not objective when it comes to testing. You better have some major facts behind your assertions (no testing pun intended) that testing is contraindicated for software and they better be easy to see, because I've lived this, like I said, for the past 14 years. I see the benefits. I am comforted by the fact that people maintaining the code I've written over the years - my code, the team's code - can be assured that it's still working, because all they have to do is to run the tests. Green is good.