5 ms·

Ask HN: Do you write unit tests for your side projects?

12 points by jmstfv 9y ago

fuball63 9y ago
The way I've always approached this dilemma is to set up my testing framework and tooling so unit tests are possible, and then write them as I find bugs in early ad hoc testing. I know its very anti-TDD to write tests from a reactionary perspective, but I find this is a good way to gradually get test coverage where it is needed while still being able to prototype the parts of the side project that are interesting.
tmaly 9y ago
I do as I find it is important to know I did not break something when I work on something over a span of time.
stevekemp 9y ago
Yes. Since, by definition, these projects aren't worked on full-time you need to know that any changes you do find time to apply are not going to kill your site/service. I don't have 100% coverage, but I do have a lot of test-cases which cover areas that are "hard". Or in response to customer bug-reports to ensure I don't have any surprises. (My service has a fair number of moving-parts, using a job-queue, service workers, a web-site, and integration with an external DNS provider, or two.)
0x54MUR41 9y ago
Yes, I do. To be honest, I did not write unit tests for my previous side projects. I just think that my codes "it works". I realized that it makes me hard to find a bug on the code when given some test cases. Developing a program is not only just "it works" but also ensure the program can handle the test cases.
pattrn 9y ago
Yes, absolutely. Due to the large number of side projects I've worked on over the years, it's very important to me that I can put something down and pick it up again later. Unit tests allow me to do that. They drastically reduce the amount of certainty I have that modifying or adding a new feature to an old code-base won't break everything.
hoschicz 9y ago
I comment them heavily and use them as documentation.
nicolasd 9y ago
Yes, I am used to it from my day-to-day job. I probably don't test every edge-case as I do in my job, but it just saves me time and brain capacity (at least I have the feeling that the coding part in TDD is the easy one).
itamarst 9y ago
It depends on the kind of code you're writing, and where it is in its lifecycle. Briefly: * Humans can determine if your code does what it's supposed to. * Automated tests can keep your code stable, i.e. make sure it doesn't change. If you care about correctness you want manual testing and code review. If you care about stability you want automated testing like unit tests. If you care about both correctness and stability you need both kinds of testing. Personally I've mostly written libraries, where stability is very important, so yes, lots of unit tests. Longer version: https://codewithoutrules.com/2017/03/26/why-how-test-software/ https://codewithoutrules.com/2017/03/26/why-how-test-softwar...
twobyfour 9y ago
Yes. Among other things, TDD lets you code from the inside out. That is, it makes it a lot easier to build and verify the business logic core of your code (which is usually the interesting part from both a technical and learning POV) without havin to first bootstrap all the additional boilerplte required to wrap an application around it to do click-throughs.
Jemaclus 9y ago
Always. IMO, it's always worth writing tests.
jfaucett 9y ago
Rarely. I just do a lot of integration/feature testing for actual projects. Most of my libraries have unit tests though cause for me it makes sense to write a unit test for things like matrix transformations or ensuring some generic gl interface func works cross-platform. But IMO its pointless to unit test a sign_in function, I'd rather just know the whole sign-in feature works.
Artlav 9y ago
More yes for deeper stuff, more no for outer stuff. I have integrated testsuit for core framework components, which can be run separately, i tend to have separate tests for more upper level stuff, and i rarely have unit tests for actual programs. It tends to be a drag that is very easy to half-ass, so i try not to waste it.
awareBrah 9y ago
Never unless they are revenue generating over a few thousand a month
flukus 9y ago
Yes, mainly around the computationally complicated parts. One of my side projects is also a test framework, so that has tests of itself using itself, in hindsight this was a poor decision.
zabana 9y ago
I always tell myself that I should skip unit tests because it's just "a side project". Then I lose sleep over it. And I end up spending an additional week and a half working on it instead of actually shipping. In my opinion it really depends on the nature of the side project. If you're going to charge users or if it's an open source project like a python package or npm module that other developers are going to rely on, it's absolutely necessary that you do. Else, meh.
fiftyacorn 9y ago
Depends on the purpose and phase - if its testing the water or proof of concept then no, if it takes off a bit then yes
1ba9115454 9y ago
No. But I do write system tests. I'm always using ruby on rails with capybara this is basically headless testing through a browser.

12 points by jmstfv 9y ago

The way I've always approached this dilemma is to set up my testing framework and tooling so unit tests are possible, and then write them as I find bugs in early ad hoc testing. I know its very anti-TDD to write tests from a reactionary perspective, but I find this is a good way to gradually get test coverage where it is needed while still being able to prototype the parts of the side project that are interesting.

tmaly 9y ago

I do as I find it is important to know I did not break something when I work on something over a span of time.

stevekemp 9y ago

Yes. Since, by definition, these projects aren't worked on full-time you need to know that any changes you do find time to apply are not going to kill your site/service. I don't have 100% coverage, but I do have a lot of test-cases which cover areas that are "hard". Or in response to customer bug-reports to ensure I don't have any surprises. (My service has a fair number of moving-parts, using a job-queue, service workers, a web-site, and integration with an external DNS provider, or two.)

0x54MUR41 9y ago

Yes, I do. To be honest, I did not write unit tests for my previous side projects. I just think that my codes "it works". I realized that it makes me hard to find a bug on the code when given some test cases. Developing a program is not only just "it works" but also ensure the program can handle the test cases.

pattrn 9y ago

Yes, absolutely. Due to the large number of side projects I've worked on over the years, it's very important to me that I can put something down and pick it up again later. Unit tests allow me to do that. They drastically reduce the amount of certainty I have that modifying or adding a new feature to an old code-base won't break everything.

hoschicz 9y ago

I comment them heavily and use them as documentation.

nicolasd 9y ago

Yes, I am used to it from my day-to-day job. I probably don't test every edge-case as I do in my job, but it just saves me time and brain capacity (at least I have the feeling that the coding part in TDD is the easy one).

itamarst 9y ago

It depends on the kind of code you're writing, and where it is in its lifecycle. Briefly: * Humans can determine if your code does what it's supposed to. * Automated tests can keep your code stable, i.e. make sure it doesn't change. If you care about correctness you want manual testing and code review. If you care about stability you want automated testing like unit tests. If you care about both correctness and stability you need both kinds of testing. Personally I've mostly written libraries, where stability is very important, so yes, lots of unit tests. Longer version: https://codewithoutrules.com/2017/03/26/why-how-test-software/ https://codewithoutrules.com/2017/03/26/why-how-test-softwar...

twobyfour 9y ago

Yes. Among other things, TDD lets you code from the inside out. That is, it makes it a lot easier to build and verify the business logic core of your code (which is usually the interesting part from both a technical and learning POV) without havin to first bootstrap all the additional boilerplte required to wrap an application around it to do click-throughs.

Jemaclus 9y ago

Always. IMO, it's always worth writing tests.

jfaucett 9y ago

Rarely. I just do a lot of integration/feature testing for actual projects. Most of my libraries have unit tests though cause for me it makes sense to write a unit test for things like matrix transformations or ensuring some generic gl interface func works cross-platform. But IMO its pointless to unit test a sign_in function, I'd rather just know the whole sign-in feature works.

Artlav 9y ago

More yes for deeper stuff, more no for outer stuff. I have integrated testsuit for core framework components, which can be run separately, i tend to have separate tests for more upper level stuff, and i rarely have unit tests for actual programs. It tends to be a drag that is very easy to half-ass, so i try not to waste it.

awareBrah 9y ago

Never unless they are revenue generating over a few thousand a month

flukus 9y ago

Yes, mainly around the computationally complicated parts. One of my side projects is also a test framework, so that has tests of itself using itself, in hindsight this was a poor decision.

zabana 9y ago

I always tell myself that I should skip unit tests because it's just "a side project". Then I lose sleep over it. And I end up spending an additional week and a half working on it instead of actually shipping. In my opinion it really depends on the nature of the side project. If you're going to charge users or if it's an open source project like a python package or npm module that other developers are going to rely on, it's absolutely necessary that you do. Else, meh.

fiftyacorn 9y ago

Depends on the purpose and phase - if its testing the water or proof of concept then no, if it takes off a bit then yes

1ba9115454 9y ago

No. But I do write system tests. I'm always using ruby on rails with capybara this is basically headless testing through a browser.