5 ms·

Something that leapt out and resonated with me here was the conscious decision not to bother with automated tests (at first? maybe they exist now). Its taken me

Something that leapt out and resonated with me here was the conscious decision not to bother with automated tests (at first? maybe they exist now). Its taken me quite a while to get over the feeling of dirtiness that comes with not writing tests, but I now take a similar approach when building toy projects for personal use after too many of them got killed by the first ~day of development, when I should have been focusing on gaining some momentum before I lost the will to build whatever it was, instead being spent putting together test infrastructure and CI pipelines. I now work on the basis that tests can be added once the lack of them becomes an issue for me.

marginalia_nu 3y ago
It's easily lost that development best practices are a function of scale. What's absolutely necessary to get anything done in a large mature project with many developers and a sprawling code base may be cumbersome in a small single-developer project.
- acedTrex 3y ago
  I'd argue a function of scale as well as a function of criticality. Not all projects need the same level of care put into them as the blast radius of bugs is... negligible sometimes
  - marginalia_nu 3y ago
    For larger projects, even trivial bugs can waste an enormous amount of time, since the number of places they can hide is much larger, and fixing them may mean blocking other work. Means that at such a scale, optimizing for correctness at all times makes sense. In a small project where bugs are easy to identify and tend to be an easy 10 minutes fix, foregoing the correctness tax and fixing bugs as they become apparent is the more economic choice.
    - robertlagrant 3y ago
      The inverse is true as well: for a project regardless of size that's part of a medical device, the economic choice isn't allowed for certain classes of bug.
    - facundo_olano 3y ago
      (I'm the post author). I agree with this. Perhaps I'd emphasize larger in terms of people working on it rather than codebase size. Once you have competing "mental models" about how the code works, the problem of silent bugs can escalate quickly. So I do think the "always test" mentality is a reasonable default for the non-prototype type of work. There's a tipping point where going on without testing can get the project out of control and it's hard to tell when that is, so in contexts where you care to avoid that risk it makes sense to be strict about it. I didn't care for that risk in this case, so it made sense not to bother and focus on building momentum. I'd probably add some integration tests now if I wanted to try a significant new feature or refactor, or if I had to consider contributions from other developers.
    - chefandy 3y ago
      Beneficial processes without sanity checks become dogma.
  - bcrosby95 3y ago
    And function of ease of manual testing. Some things are impossible to manually test without changing the actual code. For example, testing access permissions. Your UI isn't gonna display data or operations you don't have access to. But that doesn't mean your back end is honoring permissions. The other thing to take into account is how noticable the bug is. You should inch more towards writing tests for bugs that are less likely to be noticed by someone.
vidarh 3y ago
For personal projects I start writing tests when I run into something that is difficult to get right. Not before. I then focus on adding tests ad hoc when I run into problems.
ravenstine 3y ago
I generally agree, though it depends on the nature of the application. A couple years ago, I was working on a personal project where I'd built a respiratory gas analyzer and needed to write some software that could interface with it over Bluetooth and display the data in real time. Unit testing for various functions that needed to accurately perform scientific calculations was very beneficial, but in retrospect, writing tests for other aspects of the interface was pretty much a waste of time. I ended up getting rid of the tests entirely once I had confidence my functions wouldn't be changing by that point. It turns out that when you're a solo developer, manually testing your application can be perfectly adequate.

marginalia_nu 3y ago

It's easily lost that development best practices are a function of scale. What's absolutely necessary to get anything done in a large mature project with many developers and a sprawling code base may be cumbersome in a small single-developer project.

acedTrex 3y ago
I'd argue a function of scale as well as a function of criticality. Not all projects need the same level of care put into them as the blast radius of bugs is... negligible sometimes
- marginalia_nu 3y ago
  For larger projects, even trivial bugs can waste an enormous amount of time, since the number of places they can hide is much larger, and fixing them may mean blocking other work. Means that at such a scale, optimizing for correctness at all times makes sense. In a small project where bugs are easy to identify and tend to be an easy 10 minutes fix, foregoing the correctness tax and fixing bugs as they become apparent is the more economic choice.
  - robertlagrant 3y ago
    The inverse is true as well: for a project regardless of size that's part of a medical device, the economic choice isn't allowed for certain classes of bug.
  - facundo_olano 3y ago
    (I'm the post author). I agree with this. Perhaps I'd emphasize larger in terms of people working on it rather than codebase size. Once you have competing "mental models" about how the code works, the problem of silent bugs can escalate quickly. So I do think the "always test" mentality is a reasonable default for the non-prototype type of work. There's a tipping point where going on without testing can get the project out of control and it's hard to tell when that is, so in contexts where you care to avoid that risk it makes sense to be strict about it. I didn't care for that risk in this case, so it made sense not to bother and focus on building momentum. I'd probably add some integration tests now if I wanted to try a significant new feature or refactor, or if I had to consider contributions from other developers.
  - chefandy 3y ago
    Beneficial processes without sanity checks become dogma.
- bcrosby95 3y ago
  And function of ease of manual testing. Some things are impossible to manually test without changing the actual code. For example, testing access permissions. Your UI isn't gonna display data or operations you don't have access to. But that doesn't mean your back end is honoring permissions. The other thing to take into account is how noticable the bug is. You should inch more towards writing tests for bugs that are less likely to be noticed by someone.

vidarh 3y ago

For personal projects I start writing tests when I run into something that is difficult to get right. Not before. I then focus on adding tests ad hoc when I run into problems.

ravenstine 3y ago

I generally agree, though it depends on the nature of the application. A couple years ago, I was working on a personal project where I'd built a respiratory gas analyzer and needed to write some software that could interface with it over Bluetooth and display the data in real time. Unit testing for various functions that needed to accurately perform scientific calculations was very beneficial, but in retrospect, writing tests for other aspects of the interface was pretty much a waste of time. I ended up getting rid of the tests entirely once I had confidence my functions wouldn't be changing by that point. It turns out that when you're a solo developer, manually testing your application can be perfectly adequate.