4 ms·

Write tests. Most likely those 300k lines of code contain a TESST folder with 4 unit tests written by an intern who retired to become a bonsai farmer in the 199

Write tests. Most likely those 300k lines of code contain a TESST folder with 4 unit tests written by an intern who retired to become a bonsai farmer in the 1990s, and none of them pass anymore. Things become much less stressful if you have something basic telling you you're still good.

layer8 7mo ago
The problem with complex legacy codebases is that you don’t know about the myriads of edge cases the existing code is covering, and that will only be discovered in production on customer premises wreaking havoc two months after you shipped the seemingly regression-free refactor.
- mehagar 7mo ago
  I agree. This is one area I'm hoping that AI tools can help with. Given a complex codebase that no one understands, the ability to have an agent review the code change is at least better than nothing at all.
- deleted 7mo ago
  [deleted]
- UltraSane 7mo ago
  If you save a log of input on the production system you can feed it to old and new versions to find any changed in behavior.
- ljm 7mo ago
  It helps if tests are well written such that they help you with refactoring, rather than just being the implementation (or a tightly coupled equivalent) but with assertions in it. Rare to see though. I don't think being able to write code automatically means you can write decent tests. Skill needs to be developed.
  - danparsonson 7mo ago
    And the challenge with writing tests well is that it might be difficult or impossible without the refactor...
    - ljm 7mo ago
      I disagree. There is no code that can't be tested. There is certainly no code that has to be changed so it can be tested. The only reason you would decide code is untestable without touching it is because it doesn't seem worth the effort, so you test the thing that calls that code instead and mock it out. At the highest level it is all inputs and outputs after all. Your spaghetti app can still be tested end-to-end, which will cost you the most but will work. We're talking about SaaS and web apps and shit here of course, because we're on HN where downtime on Cloudflare equals a day off work. In other industries you'd be running full blown simulations and proofs and maybe even inventing new mechanisms of testing so you can get a hard project off the ground. Maybe even fabricating materials.
      - danparsonson 7mo ago
        > ...the challenge with writing tests well... Sure, you can test more or less anything given sufficient time and force, but a massive fragile harness wrapped around the system under test is not what I mean by 'testing well'. Also there are other things in software besides web; unit testing code that is entangled with desktop UI can be difficult or impossible without changing the original code. Try testing a WPF app that talks directly to the Dispatcher when there is no UI thread, for example.
- nijave 7mo ago
  You can infer based on code coverage. If coverage is low, tests are likely insufficient and change is risky
karmakurtisaani 7mo ago
The best time to write tests was 20 years ago. The second best is now, provided you've applied to all the companies with better culture.
ipsento606 7mo ago
I've been working on react and react native applications professionally for over ten years, and I have never worked on a project with any kind of meaningful test coverage
- stronglikedan 7mo ago
  over 20 years, many stacks, and same
- locknitpicker 7mo ago
  > I have never worked on a project with any kind of meaningful test coverage That says more about you and the care you put into quality assurance than anything else, really.
  - ipsento606 7mo ago
    Presumably you mean me, and every current and former team-member I've ever had? If so, you're talking about hundreds of engineers.
    - locknitpicker 7mo ago
      > Presumably you mean me, and every current and former team-member I've ever had? Yes, I mean you. You don't need hundreds of engineers to have a test suite with meaningful coverage. You need yourself and willingness to do the job. Just adding happy path tests can get you significant coverage. Why did you failed to do this? Blaming others for the problems you created and help create is not helpful. You can post PRs, can't you?
  - AnimalMuppet 7mo ago
    Have you ever worked at a place where you were put on an existing codebase, and that code has no tests? Have you ever worked at a place where, when you try to fix that, management tells you that they don't have the time to do so, they have to crank out new features? Is ipsento606 working at such a place? I don't know, and neither do you. Why do you jump to the conclusion that it's their personal failing?
cl3misch 7mo ago
A difficult prerequisite for that might be untangling a very unatomic codebase into testable chunks. And to determine a feasible "level of abstraction" to write tests for. Testing a full pipeline of a numerical library might be as impractical as testing super tiny functions, because both won't allow you to really work on the codebase.

layer8 7mo ago

The problem with complex legacy codebases is that you don’t know about the myriads of edge cases the existing code is covering, and that will only be discovered in production on customer premises wreaking havoc two months after you shipped the seemingly regression-free refactor.

mehagar 7mo ago
I agree. This is one area I'm hoping that AI tools can help with. Given a complex codebase that no one understands, the ability to have an agent review the code change is at least better than nothing at all.
deleted 7mo ago
[deleted]
UltraSane 7mo ago
If you save a log of input on the production system you can feed it to old and new versions to find any changed in behavior.
ljm 7mo ago
It helps if tests are well written such that they help you with refactoring, rather than just being the implementation (or a tightly coupled equivalent) but with assertions in it. Rare to see though. I don't think being able to write code automatically means you can write decent tests. Skill needs to be developed.
- danparsonson 7mo ago
  And the challenge with writing tests well is that it might be difficult or impossible without the refactor...
  - ljm 7mo ago
    I disagree. There is no code that can't be tested. There is certainly no code that has to be changed so it can be tested. The only reason you would decide code is untestable without touching it is because it doesn't seem worth the effort, so you test the thing that calls that code instead and mock it out. At the highest level it is all inputs and outputs after all. Your spaghetti app can still be tested end-to-end, which will cost you the most but will work. We're talking about SaaS and web apps and shit here of course, because we're on HN where downtime on Cloudflare equals a day off work. In other industries you'd be running full blown simulations and proofs and maybe even inventing new mechanisms of testing so you can get a hard project off the ground. Maybe even fabricating materials.
    - danparsonson 7mo ago
      > ...the challenge with writing tests well... Sure, you can test more or less anything given sufficient time and force, but a massive fragile harness wrapped around the system under test is not what I mean by 'testing well'. Also there are other things in software besides web; unit testing code that is entangled with desktop UI can be difficult or impossible without changing the original code. Try testing a WPF app that talks directly to the Dispatcher when there is no UI thread, for example.
nijave 7mo ago
You can infer based on code coverage. If coverage is low, tests are likely insufficient and change is risky

karmakurtisaani 7mo ago

The best time to write tests was 20 years ago. The second best is now, provided you've applied to all the companies with better culture.

ipsento606 7mo ago

I've been working on react and react native applications professionally for over ten years, and I have never worked on a project with any kind of meaningful test coverage

stronglikedan 7mo ago
over 20 years, many stacks, and same
locknitpicker 7mo ago
> I have never worked on a project with any kind of meaningful test coverage That says more about you and the care you put into quality assurance than anything else, really.
- ipsento606 7mo ago
  Presumably you mean me, and every current and former team-member I've ever had? If so, you're talking about hundreds of engineers.
  - locknitpicker 7mo ago
    > Presumably you mean me, and every current and former team-member I've ever had? Yes, I mean you. You don't need hundreds of engineers to have a test suite with meaningful coverage. You need yourself and willingness to do the job. Just adding happy path tests can get you significant coverage. Why did you failed to do this? Blaming others for the problems you created and help create is not helpful. You can post PRs, can't you?
- AnimalMuppet 7mo ago
  Have you ever worked at a place where you were put on an existing codebase, and that code has no tests? Have you ever worked at a place where, when you try to fix that, management tells you that they don't have the time to do so, they have to crank out new features? Is ipsento606 working at such a place? I don't know, and neither do you. Why do you jump to the conclusion that it's their personal failing?

cl3misch 7mo ago

A difficult prerequisite for that might be untangling a very unatomic codebase into testable chunks. And to determine a feasible "level of abstraction" to write tests for. Testing a full pipeline of a numerical library might be as impractical as testing super tiny functions, because both won't allow you to really work on the codebase.