Timeline for How to initiate unit testing when you're the grunt?
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 13, 2023 at 18:30 | comment | added | J_H | Yup. It is often enough I have told my colleagues to their face that "I don't believe your ReadMe". Sometimes during a PR, but usually six months later when they've added something to the code without changing ("maintaining") the ReadMe. When I peruse a comment or ReadMe, I take it with a grain of salt, whereas I always believe what a Green test is telling me. Often they are designed to have instructional value, for prospective callers. The brilliant thing is, when features are added, we choose to fix a test or simply prune it if it's no longer worth it. Dead tests tell no lies. | |
| Mar 13, 2023 at 17:35 | comment | added | Steve | Continuing the analogy with documentation, nobody anywhere denies the value of good documentation. But actually making documentation to a standard, and then keeping it current, is far easier said than done, and it really only works reliably when available resources are such that it is possible to retain an expert on staff (or to have so many staff that an expert might naturally be found amongst them who can lead others by example). (2/2) | |
| Mar 13, 2023 at 17:34 | comment | added | Steve | @J_H, I agree, and I think the question "how do tests deliver benefits?" would have a multi-faceted answer. But I think tests also impose costs and constraints, not only in the initial development, but in terms of maintenance effort when things change. The communicative aspect suggests that tests are a kind of coded documentation, but except for the advantage of executability, I suspect tests-as-documentation suffer from similar pitfalls as documentation itself. (1/2) | |
| Mar 12, 2023 at 19:03 | comment | added | J_H | I agree that bad designs and sloppy tests are definitely a thing. It's often enough that I've asked a colleague to delete or change a test before a merge. But I feel an aspect that's missing from this conversation is the kind of clear communication that tests facilitate. Bob ran a manual test a year ago, fine. But now I want to run that function, and I do what, consult a ReadMe? Chat with Bob? Read the source to figure out suitable environment + input arguments + interpretation of output? Maybe. Or I just run the test, setting a breakpoint. Plus, a year later, does Bob remember details? | |
| Mar 9, 2023 at 15:26 | comment | added | Steve | @tageta72, well certainly they may be cowboys by some other standard, including the quality and integrity of the design. But people who conceive bad designs are just as likely to write sloppy tests. If you say he's a cowboy because his design stinks, then you're head-on with the issue. If you say he's a cowboy because he doesn't have a suite of automated unit tests, the argument may fail to land simply because unit testing is (in my experience, and without expressing opinion on the value of automated testing...) not widespread for bespoke/in-house development. | |
| Mar 9, 2023 at 2:37 | comment | added | tageta72 | To clarify, not ALL of my colleagues are dead set against it. One is dead set against it, who is a middle manager. The head of the company (who is also lead dev) just sees it as a "nice to have" to be shelved. The other devs I have almost no contact with, and I have no idea their opinions on the matter. As for whether they are "cowboys", the lack of testing is but one factor. They routinely make ad-hoc design choices that are damaging to maintainability, and do so in many ways. I'm sure there are many senior devs who don't follow standards but do keep maintainability, but these aren't them. | |
| Mar 8, 2023 at 21:42 | comment | added | Steve | @DocBrown, certainly if there would be repetitive manual testing, then it makes sense to automate. However my assumption was not that the alternative to unit tests would be repetitive manual testing, but no testing at all beyond that done manually during initial development. | |
| Mar 8, 2023 at 17:35 | comment | added | Doc Brown | Where I agree is that experienced, old-school programmers should not be considered to be "cowboy coders" just because they haven't discovered the value of unit testing for their work (yet). However, the very wrong assumption in this answer is that unit testing is a technique for "large businesses with industrial software production and/or very sensitive code". Quite the opposite: the right amount of unit testing can help to use the spare resources of a small team more efficiently, since it can automate the boring, time wasting, cumbersome work of test repetition. | |
| Mar 8, 2023 at 16:56 | history | answered | Steve | CC BY-SA 4.0 |