

Ask HN: Do you write unit testing when creating a new product? - Avalaxy

When you're working on a new product, you want to move fast and release an MVP as soon as you can. This contradicts with the practice to create unit tests for all your code, since unit test code can easily take up 50% of your code base. So my question is: do you write unit tests for your new products? And if not, do you take test-ability into account (i.e. by using dependency injection)?
======
noonespecial
I don't write the tests. It takes to long when I'm exploring a problem space,
but I do write or at least think about test conditions and what it would take
to satisfy them.

I find that if I can't easily imagine how I would create a test for the code
I'm currently banging on, I don't have enough encapsulation yet to arrive at a
workable solution.

------
DanielN
The testing rules I code by:

\- will someone else be touching the code? If yes then I TDD

\- Am I likely to be touching the code six months from now? If yes then I at
least document with tests.

\- Is it a crucial piece of code who's specs I want documented? If yes then I
document with tests.

------
eranation
only in job interviews, in blog posts, when commenting in HN or answering
stackoverflow questions, and only when I have a budget to do so. In other
cases, I just try to write self debugging code (assert things, think of edge
cases, good logging, never take anything for granted). e.g. I test the code
within the code. instead of writing an external test, my test code is within
the code, not sure if it makes sense, but that's how I get to do things both
fast, and keep quality.

HOWEVER, if I have unit tests available, this is priceless, so if I can have
the budget and time to write them, I would, but if writing tests would mean
you avoid writing code, just write code (unless you work for SpaceX or NASA)

And to your point, if it's an MVP? I would say ditch the tests at first, it's
better to test your idea and market, than test code that might be thrown away.
and you should plan to throw away your MVP. you won't be able to live with
yourself if you don't. just call it garbage code, and if you get traction,
just rewrite the whole thing. it might be a lie your are telling yourself, but
if you over engineer your startup, you might end up not knowing if it's true
or not.

------
Avalaxy
Just to start with the discussion: I don't. I feel like it takes up too much
of my valuable time (I'm working on my own, so I need all the time I can get).
I do however build my software with test-ability in mind (more or less, I
probably have to change multiple things if I really want to unit test my
code).

------
dholowiski
As someone who has bootstrapped themselves to a basic level of coding
knowledge thanks to Google, I'll ask the potentially stupid question: How do I
learn how to do unit testing? I know what it is but I have no idea how to go
about it. Resources?

~~~
eranation
What is your language? the answer can be rspec, junit, selenium, etc based on
the language and framework.

basically unit testing is on the function/class/module basis.

you break your design into modules, each having a clear role, and make them
plug into each other in a way that you can "mock" the "rest of the world"
(e.g. other objects) and test only that part.

to give an example, let's say you create a car, the unit test is to take a
wheel, and spin it as if it's on the road, but without a car. take the lights,
and plug them in as if they are in the car, take the engine and run it as if
it's connected to the transmission, etc. in a car it's a bit more difficult,
but in code, if your view needs a model, it doesn't matter if it was created
from a database, a text file, or coded, as long as the interface fits.

------
dreamdu5t
Most will tell you they test. Few do.

