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 DEBUGblock 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:
- Irrevocably disturbing my coworkers and manager's very "cowboy" workflows
- Digging myself into an unmaintainable pit that only wastes time better spent elsewhere
- 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.