Save the code or save the tests? (2020) • Hacker News Board

Re: Save the code or save the tests? (2020)

#31

Post by yoyonamite » Sat, Jun 12, 2021, 2:03 AM UTC

lmilcin wrote: post #20

I see how I am going to be downvoted to hell, but let's give it a shot: I just refuse to write tests. I think it is complete waste of time. Here, I said it. My preferred style of working is writing something and then refactoring it to my satisfaction. I toy with interfaces as I discuss meaning of various things, learning in the process. I am mercilessly cutting stuff that is not necessary, finding ways to make everyt…

I do think it's important to think critically and not just do something for the sake of doing it. Testing well is not easy to get right. If your tests are constantly changing, then the tests are probably too coupled with the implementation. However, I think it's safe to say that the user wants some level of consistency in the product. If your tests captured what needs to stay consistent, you should theoretically see less churn in the test code.

There are other ways to get a stable system. It seems like the code that you're working on doesn't see much code churn and you have a good understanding of the system. This is definitely a situation where I see testing not being as valuable.

I think one of the big reasons testing is considered a good practice is we're relying more on dependencies that need to be updated somewhat frequently, and semver is not taken as seriously, especially in certain web ecosystems. There's a decent chance you don't work in such an ecosystem where it's not an issue, but that's the biggest reason for me to advocate for testing.

The other big reason is that it's easier to make changes in a codebase that you aren't familiar with when tests are available. This is especially true with software that may have non-obvious corner cases.

Re: Save the code or save the tests? (2020)

#32

Post by aszen » Tue, Jun 15, 2021, 2:44 AM UTC

lakis wrote: post #30

aszen wrote: post #27

Earlier quoted context omitted.

I'll try to justify, imagine you have working code with no tests, it's been running for years but no one can understand it or change any of it. It's providing a very fixed value. Now imagine you have all the tests laying out exactly how the features should work. Sure you don't have anything to show for yet but it's not going to take a lot of time to implement these features. The hardest part in most companies is not…

> it's not going to take a lot of time to implement these features That's so wrong. Have you ever worked in a complex program?

Yes ofcourse. Having tests helps a lot, take as example someone building a markdown parser. If u have the knowledge of how to build parsers, then an existing suite of tests is going to speed your work quite a bit by ensuring that you build the right thing and covering the exact features you need without any ambiguity.

Ofcourse I do realise that in real world examples there's not many test cases which cover a feature fully. But this was all thinking hypothetically.

Re: Save the code or save the tests? (2020)

#33

Post by aszen » Tue, Jun 15, 2021, 2:47 AM UTC

cogman10 wrote: post #28

aszen wrote: post #27

Earlier quoted context omitted.

I'll try to justify, imagine you have working code with no tests, it's been running for years but no one can understand it or change any of it. It's providing a very fixed value. Now imagine you have all the tests laying out exactly how the features should work. Sure you don't have anything to show for yet but it's not going to take a lot of time to implement these features. The hardest part in most companies is not…

I have worked on exactly that sort of code base. I've also worked on codebases which did super test coverage. And honestly, the 0 test coverage base was actually easier to deal with. Tests are good, but like all code they can be implemented poorly.

Some test cases are really important and cover the whole domain, take as example the tc39 tests, they are really all you need to fulfill to create a compliant javascript implementation.