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

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.

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.)

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-softwar...

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.

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.

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.

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.

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.

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.

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).

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

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.

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.

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

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

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

I comment them heavily and use them as documentation.