Ask HN: Do you write unit tests for your side projects? - jmstfv
======
pattrn
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.

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

------
itamarst
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...](https://codewithoutrules.com/2017/03/26/why-how-test-software/)

------
0x54MUR41
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.

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

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

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

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

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

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

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

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

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

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

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

------
fiftyacorn
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

------
hoschicz
I comment them heavily and use them as documentation.

