| - "Talks a lot about progress"... this is a mixed bag. if you're producing code, it is not just talk. i'm talking about a scenario where you've heard about the great struggles they've faced, and after a week you get a commit with 4 files cahnged, and it's on a "sample" of the full work. overdone is fine and not what i meant. - "Says shit like I don't write tests". I don't write tests. There are good reasons that are out of scope of this discussion. This mindest is the same to me as saying "we only need a single point of failure for all things". "I can just read the source" is the same thing as saying "i can just take a course on it later that will take hours without the help of the original context". I firmly believe that anytime you build a big suite of software without tests, you're just unloading tech debt on an org with no guidance on how to handle it. comments, tips, and tricks can drift from the code overtime, a test can't and is the only provable way to validate your code. if you don't have time for testing at work it's an organizational failure that will only come due in the worst of times. Remember when Jira deleted a bunch of shit and couldn't get it back without one engineer fixing it manually? boy, i bet it would've paid to have _any_ testing in there! - "You repeat same comments in loops because thy aren't taking feedback". When you tell someone "commiting secrets to the repo means they are no longer secret" and they go oh yeah, makes sense, and then proceed to dump credentials into the next four commits, that's what i'm talking about. not this "i dropped a whole new concept on you. learn it in one" concept that i may have implied. i'm talking about poeple who just aren't even trying to listen, they just want an approval or w/e from you to move on. fwiw: i'm a bit of a stickler for testing, and will acknowledge that my stance comes from my experience, and is therefore a known bias, just one i have a hard time letting go of |
It is not that I believe tests do not work. Tests is a viable solution to a problem. The issue with tests is that you have to do a lot of things right and you have to structure your development in certain way for tests to be productive. And if you don't do a lot of things right then tests will just cost a lot of development time without much benefits.
Introducing unit testing is hard if your team isn't already doing it and costs a lot of effort for practically no immediately visible effect to stakeholders.
Very few organisations I worked in would be at maturity level when investing in unit testing would be the highest return on investment thing you could do at the moment. There is usually many other problems that cause less disruption to development practices and bring much more benefits than unit testing.
On the other hand I am a huge fan of functional testing where you create a test harness that ensures that public interface of your product (application) functions as expected. The effort is much smaller (you only evaluate public interface which already is integrated with other things and which isn't expected to be changing a lot anyway), the benefits are clearly demonstrable and understood by stakeholders.