Ask HN: Do you write unit testing when creating a new product?
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)?
8 comments
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.
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.
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.
- 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.
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.
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.
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).
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?
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.
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.
What language are you using? If it's Java I found 'Test Driven Development' by Kent Beck a great book if you want to 'get' unit testing and TDD.
There's a gap before when the point of TDD 'clicks' and you see the 'why'; before that it can seem a huge bore. After that it can seem a bore too in some situations but you can see the benefits of it.
There's a gap before when the point of TDD 'clicks' and you see the 'why'; before that it can seem a huge bore. After that it can seem a bore too in some situations but you can see the benefits of it.
Most will tell you they test. Few do.