How to initiate unit testing when you're the grunt?

Question

I am the newest programmer on a very small team of 6 developers, 3 of which are offsite. By "newest" I mean both in years of experience (drastically) and familiarity with the code. I've been with the company for a couple years, though only recently shifted towards programming. I have no formal education on programming (be it degree, certificate, or otherwise), only experience is some very poorly-made hobbyist projects over the years. My co-developers and manager all have 30+ years professional programming experience, several of whom have been with the company since its start 20 years ago.

Naturally, the code I'm working with is a big ball of object-oriented mud (C# .NET Framework). It's not important what's specifically wrong with the code itself, just that it's very much a victim to legacy code rot. I've been scouring SE questions on how to deal with this, and been reading Working Effectively with Legacy Code as is often prescribed. Most of what I've found points to slowly and gradually getting the code under unit testing, starting with new code we write.

I've looked at Joel On Software's post regarding trying to improve things as the grunt, and it (and other SE posts) say to lead by example, to just start with it in my own work. Theoretically, if my code has test coverage, and it proves to be far easier to maintain, then that on its own could convince others to consider it.

The trouble is, I don't think I'm really in a position to start the overhead needed to begin implementing testing. My coworkers and boss, who all have far more experience than I do, have no intent on testing. I've asked briefly before about unit testing, and it was brushed off as "not a priority". At least one of my coworkers is outright opposed (ideologically) to unit testing. As the newest dev when the others have decades with this codebase, I think it'd be stepping out of line for me to try to press the issue further.

And from a technical side, almost everything I see on unit testing seems to make some assumptions that might be problematic for me:

• Using a unit testing framework (presumably NUnit for .NET). This adds an external dependency to all the project files that we start putting tests on, and I'm not sure that would be taken very kindly.
• Creating additional build/run configurations. From what I can tell, adding unit testing would require added build configurations, an additional project to load the test classes (with its own dependencies), or an #if DEBUG block in each runnable project's Program.cs to kick something off prior to debugging. There are 150+ projects all compiled together in one SLN, changing that much might not come across so well.
• Being in a position to make structural changes needed to get a class in a test harness. Most of the programming I've been assigned has been smaller fixes buried within monster classes. I'm not sure slapping down a new interface to get a class under test when I'm assigned a bug fix is something that will go well.
• Other team members being willing to run tests after they're added, and fixing tests that break when intended behavior changes. Nobody else on the team has any interest in unit testing. If I start writing tests, I'll be a steward to those tests and have to adjust whenever my coworkers break them.
• Having a relatively unified VCS branch structure. We have a lot of long-term (upwards of 9 years unmerged) production branches, with a variety of fixes and features pseudo-cherry-picked inconsistently between them. A test that works in one branch is quite likely to need to be entirely different in another due to a lack of behavioral parity.

This office very much has a "just fix the here and now" attitude with software. If it's not an easy fix or an immediate and severe problem, it gets shelved indefinitely. We don't even have an issue tracker, so any lingering bugs just get forgotten. Any long-term infrastructural problems (testing, unsupported dependencies, issue tracking, misuse of branches) all get dismissed, because something else is always a higher priority.

Is it reasonably possible to start working on unit tests in an environment like this? And do it without:

1. Irrevocably disturbing my coworkers and manager's very "cowboy" workflows
2. Digging myself into an unmaintainable pit that only wastes time better spent elsewhere
3. Overstepping my bounds and risking my job as the lowest ranking dev

To be clear, I am not advocating to start slapping tests all over the existing code and ignoring deliverables. I understand that sometimes things just have to get done. But gradual improvements along the way (which I do have time for) would really help, given how unwieldy the codebase is.

Maybe this belongs in Workplace SE instead, if so I apologize. I'm hoping there's some kind of technical solution without having to worry about interpersonal difficulties, so I'm trying here. Please move this question if I am mistaken.

---

TL;DR - New inexperienced dev on a small team consisting entirely of devs with 30+ years experience. Codebase (C#) is demonstrably difficult to maintain, with no automated testing whatsoever. Long-term improvements are always dismissed as "not a priority". Want to gradually work on unit tests, but no manager approval and no coworker support. Wondering if and how it might be possible to "boy scout rule" them in a way that doesn't disturb the cowboys or overstep my bounds.

Answer 1

You are working on project S, which lacks CI/CD nor even the ability to see an NUnit green bar. Presumably it exports at least one public function you can call. Create project T, which calls one or more S functions. You can decide later on whether you tell anyone about T. Incorporate any external dependencies you like, verify some trivial property, and admire the green bar. Wait for next sprint planning session.

You are assigned a new item, a feature or bugfix, so you will add at least one new public function to S. You will have to run this code, more than once, and evaluate its results. Avoid printf debugging or eyeballing the GUI or whatever approach is customarily used with S. Write a Red (failing) test in T, then iterate until it is Green. At this point, S has good code committed to successfully close out the sprint.

When the subsequent sprint begins, you're assigned an item that requires you to interact with colleague Bob's function b(), but you have no idea how to call it nor how to verify the result. Rather than add paragraphs to some ReadMe explaining this, just add an automated test that covers b(). Now when you make changes, you can tell if you broke things, or anyway if you broke the covered behavior of interest. Add your new function f() that calls b(), and write a test for it. Close out the sprint with both S and T in better shape than when the sprint started. Why did we write these tests? To improve your productivity, so the feature is released quickly and correctly.

Get GitHub Actions or Jenkins or some other CI/CD approach to routinely run tests when new code is pushed. As calendar time goes by it will develop a history of either false alarms or valuable alerts. Decide later if you want to tell anyone about it.

---

What's wrong with S + T ? Oh, so many things, both technical and social, let's not count the ways. Perhaps the biggest is that commits across both are not atomic. So git is not your time machine. You might be able to clumsily synchronize times with a pair of checkout commands, to reproduce some regression and its fix.

After you've been doing this for six months, there will be some bug that is significant enough that it will need power tools to fix, and folks will be grateful to have good tools handed to them. Seize the opportunity, drag a bunch of code into a "test PoC" branch in S, and pitch your approach. Maybe it gets adopted a few sprints later after the current emergency has been dispatched in the accustomed way, but hey, that's still a victory.

---

Much of the planning for project initiatives is about de-risking them -- systematically exploring items that could jeopardize KPIs and choosing to abandon the item or adopt it, perhaps with adaptations from lessons learned. Your investment in automated testing serves your own productivity, and may pay dividends when the team can clearly see a different set of {risks, rewards} than they saw last year.

Answer 2

It seems impossible to implement unit testing on a shared codebase, where every single one of your colleagues are dead set against it.

It's not clear whether this refusal is a "cowboy practice" however. I've worked in businesses big and small who have bespoke applications, and I don't recall any that were covered by unit tests, and I've never used them myself. I've not worked at NASA though, nor at a major global software vendor.

I think the crucial thing to note is that certain "good practices" are only justifiable in the largest businesses with the most sensitive code.

When smaller shops dispense with many things which are typical of larger operations, it is no more a "cowboy practice" than a master carpenter working alone, who does not have a quality system, a health and safety manager, or machinery costing millions, because the scale of his operation does not justify that.

There is a difference in style between industrial production and craft production certainly, but master craftsmen are not conventionally considered "cowboys" simply because they do not follow industrial methods.

Answer 3

Joels article assumes management and colleagues are at worst ignorant or indifferent towards the better development practices you want to introduce.

But in your case it seems management and seniors are actively opposed to unit tests. This is a very different scenario. It will not end well if you try to stealthily do work management think is detrimental to the business!

Introducing unit tests on an existing code base that is not designed for testing will require some level of restructuring across the code base. There is no way you can do that without some buy-in from your colleagues. They might not want to write unit tests themselves but they need to at least be willing to have you give it a shot and not actively sabotage it.

You mention the senior who is "ideologically opposed" to unit tests. But you don't say a word about why they are opposed. I guess this means you never asked? But you can't get anywhere without listening to and addressing their concerns. There are plenty of examples of unit tests being used wrong and just becoming a general drain on resources without providing any increase in code quality. The person might have experienced such a project.

You need to listen to their concerns before you will get anywhere.

Answer 4

An alternative to unit testing are lots of assertions.

What you want isn’t really unit tests, but the ability to spot bugs when they are introduced, and to be more certain that there are no bugs. And exact knowledge what code is supposed to do. Good unit tests are very helpful for this.

But if people are opposed to unit tests, then lots of assertions can achieve the same to a degree, and are harder to oppose because they are an old standard technique.

Answer 5

The rocket science of "boy scout rule" is to "stir the tea with a teaspoon", is to "mind your business", persevere and things will get in motion thanks to what I guess in physics is called sympathetic movement, in business is called disruptive business, in software development is called incremental development, in management is called bottom-up approach.

The question is by what methods could experienced developers perceive the benefits of changing the way they develop software. It depends. The way software is developed "passed the test of time" and it keep passing it; it's influenced by the contexts it has been developed through. Adding new techniques to existing code could be non-intrusive; unit testing new code is concerned with new code, is the side car pattern from containerisation design patterns; interlacing new and existing code implementing design patterns, bridge design pattern to mention one without knowing the details.

Bottom line is when there isn't anything better to do roll up your sleeves, peek your tools, persevere and have fun.