|
Let's say I'm a newly-joined senior Java developer, assigned a code base that's a couple years old and fairly sprawling. Test coverage is ~12% on average for the 5 repos I work in. I see a clear need to add more unit test coverage, but here's the deal: We can't do it all, and even if we could, I need to prioritize the most important code first. Tools already at my disposal:
Also, any advice for metrics to help prioritize? My thinking right now is that two metrics will help me:
And what tools can help me find the most-changed files? (Git blame is useful, but only reports on a single file at a time. I'd like something that gives me a breakdown for the whole repo, at least.)
|
#
?
May 12, 2023 23:21
|
|
|
|
| # ? May 4, 2024 03:38 |
|
|
Hippie Hedgehog posted:My thinking right now is that two metrics will help me: Metrics aren't really your best friend for sprawling untestable code bases - I would say up front you should do a few things;
|
|
#
?
May 14, 2023 23:19
|
|
|
Thanks for these pieces of advice! Will definitely ask around about which code is "scary" to the devs. I have an idea myself after looking at it myself. One good thing is this particular code base is not generally hard to write tests for. It's just that people have not taken the time for it. Anyway, duplication doesn't seem like a huge problem right now, at least as far as Sonar indicates. I'm mostly concerned with some really complex methods that are impossible to break up because people mindlessly just added special cases over a few years, and need new abstractions. Hippie Hedgehog fucked around with this message at 09:21 on May 15, 2023 |
|
#
?
May 15, 2023 08:56
|
|
|
Hippie Hedgehog posted:One good thing is this particular code base is not generally hard to write tests for. It's just that people have not taken the time for it. If I had a nickel for every time I'd seen that one at a job, I'd have six nickels etc. I don't even count the number of times I've heard this or something similar from people in the industry who I don't work with directly. I would strongly emphasize cynic's "quality gate" strategy -- a lot of this will have to do with your build system. This should include at a minimum: Tests run on every pull request; you can't merge code if it doesn't pass its tests, even as an administrator/spooky scenarios; and, you have a minimum metric of test coverage (percentage) in new code. Combining that with the easy-win stuff should highlight areas for improvement -- often what I find in writing tests is not merely duplicated code but also code that is worthy of removal/refactoring as part of the test suite. Obviously all of this is super easy to say. I'm rooting for you.  -- last thing I note is that obviously I'm a big proponent of Maven in these scenarios, but I note that you don't include that part of your build toolchain here. Anything in that space we could improve as part of the test push?
|
|
#
?
May 16, 2023 04:07
|
|
|
I didn't include Maven, right, yes that's the build tool. Might as well have been gradle or something else, though, I don't think maven by itself will help me. I think we're setup well for gating this using sonarqube's coverage gating, so I'm not worried about that. The new code is easy, looking for how to find the proper place to start covering the legacy code. =)
|
|
#
?
May 16, 2023 09:12
|
|
|
|
| # ? May 4, 2024 03:38 |
|
|
The way Maven can help you here is enforcing your code coverage and (with an artifact repository) helping you extract functionality at a dependency level via a release process (which may help improve the architecture). If you don't have an artifact repository hanging around (Nexus, GitHub Packages, Artifactory, etc) feel free to ignore this portion of advice. A solid if verbose example is the parent->child architecture with jacoco enforcement; cf. https://github.com/infrastructurebuilder/ibparent/blob/master/pom.xml#L1465 and a downstream project https://github.com/infrastructurebuilder/audit-reporting-maven-plugin/blob/develop/pom.xml#L31; note how the use of a released parent allows you to enforce this configuration on downstream projects consistently and track that the covered percentage goes up. Additionally, this allows you to pull things away from the legacy architecture with its boatload of bespoke cases. One of the things I would look at would be drilling into the 'complex methods' you mentioned - can they be pulled away as a dependency? If not, why not? Getting that away from the main code may give you architecture/refactoring ideas and then enables you to write the tests covering such things in isolation. Of course, writing testable code isn't always the goal of such things originally so ... yeah, daunting. Again I'm armchair quarterbacking here so don't take my advice as law, ymmv, etc.
|
|
#
?
May 16, 2023 11:44
|
|