4 ms·
I too keep wondering where this path leads. One thing is clear to me though, creating (software) by yourself is a completely different activity from doing it i
by codr7 2y ago
I too keep wondering where this path leads.
One thing is clear to me though, creating (software) by yourself is a completely different activity from doing it in a team.
About testing. Tests are means, not ends. What we're looking for is confidence I think. So when I feel confident about an implementation, I'll test less. And if I desperately need to make sure something keeps working, I'll add a few integration tests at the outer edges that are not so affected by refactorings and thus won't slow me down as much. E.g poking a web backend from the outside, as opposed to testing the internals. Unit tests are good for fleshing out the design of new API's, but those tests are pretty much useless once you know where you're going.
- sebstefan 2y agoPlus there's so many good reasons to have tests in a single person project * Hotwiring if statements with "true ||" to go straight to the feature you're building takes time, and you're gonna have to tear it down later. Just build a test and run it, that way you get to keep it for regression testing * If you're shipping something big, or slow, (which can just mean 'I use qt' sometimes) and launching the app/building the app takes ages, just make a test. A single test loads quicker and runs quicker * If you're debugging and reproducing the bug takes 45 seconds, just write a test. It automates away the most boring part of the job, keeps your flow going, allows you to check the status of the bug as often as you want without having to think about if it's worth it or not, and, same as #1, you get to keep the test for regression testing
- akkartik 2y agoI favorited your comment, thank you: https://news.ycombinator.com/favorites?id=akkartik&comments=t https://news.ycombinator.com/favorites?id=akkartik&comments=...