Comment by faizshah | Hacker News Reader

Comment by faizshah | Hacker News Reader

Parent Full thread

Wholeheartedly agree to everything you’ve said.

I have worked at a lot of places where automated testing is almost non existent. Instead they use staging/testing environments and manual testing.

For all these projects they frequently have downtime or errors in prod where something was uncaught. It takes ages to release a fix because they have to carefully research how a change affects other code instead of running a test suite.

They are convinced that unit tests are unnecessary extra work for their project but they don’t realize they are losing time by having to manually test and research changes. I think a lot of the focus on fancy testing practices has lead some programmers to think testing is a load of extra work when things will fail in prod anyway. We need to push back and say automated tests are a way to codify assumptions about the code and help speed up the prototype-build-test-release loop.

Side-note: self documenting code is a myth but I digress.

> They are convinced that unit tests are unnecessary extra work for their project but they don’t realize they are losing time by having to manually test and research changes.

If people are finding tests unnecessary extra work, maybe they're right for their project.

Most jobs are just "ship feature asap, try not to break anything, repeat". Most managers don't care about code quality as much as speed of delivery. Most coders don't have much "skin in the game" and can always get another job when the project fails.

Writing tests is a sign that you know what you're building, you have a methodology for building it, and you have a commitment to keeping it working in the future. That's simply not the requirements for most programming work, and it can be a disservice to both the coders and the management to push for testing that won't help achieve the business goals. If a business needs to iterate fast and reliably, write tests. If a business needs to iterate fast and is ok with breaking things, skip the tests and have a rollback plan instead.

Sorry, I have to completely disagree with this. This is a horrible, but often used, excuse.

In my experience these coders are doing exactly what you would do in a unit test but instead they are doing it manually by adding printlns and testing various values on the command line, in a repl, a notebook, or a main. Instead of manually adding these things every time you want to test your work, if you just added some basic unit tests it would speed up your delivery. Not only that but you can't "forget to test that" because you're forced to write down the test cases instead of deleting them when you're done.

If you add up all the time you spent adding printlns to your code, testing various input values in a main method, researching inside your codebase to see what could fail, debugging your ETL because you forgot about an uncaught error or a different kind of null in this column that only came up after it processed 3TB of data (real example), etc. I guarantee you would save time if you just implement some basic automated tests instead of testing in prod or staging.

Then, may I present the argument that, in general, you should be testing if for one reason: to get practice writing tests for when you actually have a project that you need to write tests in (edit: according to your metric).

Managers need developers to write tests so that when that developer job hops the new dev on the team can actually make changes with confidence. As it happens, writing tests and adhering to best practices has a side effect of keeping turnover low because developers can do their jobs with less friction.

I don't disagree, probably.

I keep finding myself working on internal projects that are driven by a UI and have little business logic but lots of I/O to other systems. With no hard requirements, no guarantee of shipping and no direct access to end users. Which I find less suited to unit tests than (automated) integration testing. As soon as you put unit testing in all anyone can ask is what your test coverage percentage is and why it's some value less than 100.

Unit testing is a dev tool, if a dev sees value in writing and maintaining a given test, great, otherwise it could just be that it's not a panacea. Let them strike a balance but ensure the team ask the question of any production issues - could a unit test have prevented this?

Yeah no.

The biggest issue in all my dev work so far was a really shitty codebase which would work somehow and had and still have hidden big issues going on.

You just don't see it today perhaps and delivered it in 1 day instead of 3. But you will fix the issue in production half a year later and either have lost data, corrupted data or you have to correct data.

Not doing any tests, is literally shit.

Missing Unit tests also often means no proper CI/CD pipeline. Because yeah why would you need a proper build if you don't even execute tests anyway right?

IT IS always a clearly ignored requirement of doing proper work. Quality work. Do less, do better. Its the fault of the manager to not think about it and enforce it and its the fault of the developer to build shit.

Self-documenting code is all code. The only thing that speaks to what a piece of code does is the code. Comments aren’t syntax, so they don’t help you there. I’ve never seen a codebase that does a good job of documenting the system architecture, expected usage patterns, and why the code is built the way it is. And I don’t know that having all that be inline to the code would be helpful anyway.

I find it far less error prone to just read the code and determine its purpose and allowable modifications from that. I am thinking about what a citation or footnote system might look like for code now though. That has the potential to provide context on-demand without needing to separate out all the pieces of the code into little silos that are hard to piece together.

Self-documenting code is a total myth. Instead of the author documenting what a piece of code does, why it does it that way and how to use it everyone who works on that code has to spend hours looking through the commit history, merge requests, design docs, wiki history, asking around etc piecing together the history and conversations around the code.

Sometimes these artifacts don’t exist so then you have to go do the same research the author did to write the code just to figure out why the code exists...

Note that none of those activities are reading the code itself because you can do that in both scenarios.

Reply on news.ycombinator.com