HN Explorer

Ask HN: How can a successful startup adopt a strong testing workflow?

9 points by notdonspaulding ↗ HN
We're a small group of "cowboy coders" who tend to let our end users be our test suite. We've gotten pretty far with this, but lately we've seen the ill effects of not testing. We can see that in order to grow we're going to need to bolster our workflow with a real testing methodology. But while we're proficient at several languages, we didn't "grow up with" a test-driven culture.

Has anyone successfully retrained themselves from a code-first, test-maybe mindset to a code-whenever, test-always mindset?

Is it easier to do this as individuals or as a team?

Is there any advice you would give to someone who knows how to code but doesn't know how to test?

7 comments

[ 3.2 ms ] story [ 39.2 ms ] thread
cblock811
My previous startup didn't do much in way of testing early on and the end users certainly felt that. Even later on the things I worked on didn't get test coverage because it wasn't considered a priority.

Now I'm at a startup where it's just myself and another engineer working on the product. He was keen on testing, so we chose a testing framework, and now we include tests when we push code.

My advice: Pick a testing framework as a team, learn it, use it. Start writing tests for your previous code. This will be painful and you'll probably have to refactor a lot. That's just how it goes, but your product will be better for it. And in the future if code being pushed doesn't have tests, it doesn't get released. That works for us and it worked for me.

tetonraven
I would suggest committing to just try it. If you give an honest try at putting quality and testing center-stage in your development, I think you'll start to see the value and eventually get hooked on it. Start with unit tests and grow from there. There was a time when I thought unit tests were a "nice-to-have-sometimes" sort of thing. Now, I fully embrace TDD and writing tests (first) is an integral part of my development. This has grown into a comprehensive test strategy with automation at various levels. Maybe it sounds simplistic, but just start with forcing yourselves to write unit tests for all new code and see where it takes you. Be sure you are writing good tests, though, otherwise you'll reinforce a non-test approach by seeing poor outcomes; there are a lot of sources on how to write good unit tests.
lacker
Jumping straight from cowboy to TDD is a big change. I suggest a much simpler rule to get started: whenever something breaks in production, add a test that ensures it won't break again. That's all!

Taking a small bite of testing ensures that you actually see the value of unit testing without going nuts and totally changing your development process. Once you have that much going, you can do more testing.

davismwfl
I totally agree. Having been in the same shoes this is the best route usually. I am all for setting up CI and have the ability for a failed test to fail the build etc, but start simple. Pick a framework you can all agree seems reasonable and write tests for things that break. Then as you add new code write tests there too.

As you do this you will quickly wind up with 10 then 30 etc and the tests will just start building up and before you know it you have a serious test suite and your mindset will have shifted.

Personally I do not start a new project with TDD. I know I will likely get smacked for admitting it. But to me get the basic app whipped into a useable product then introduce more discipline via testing this way. That way yes you pay some for it, but you have clients or a slid demo etc. Writing a great app with tons of tests that misses the mark doesn't benefit anyone. Faster iteration early on is more important. Of course I caveat this some, if you are adding a component to an already built system or in an enterprise I'd likely build tests first.

ZainRiz
Exactly. As you try to write tests for things that break you may find that it's actually really hard to write tests. You need to initialize a database, or your code depends on X, Y, Z, and they all need to be setup.

This is an opportunity for refactoring.

Try to refactor just the code that's affected by the bug in a way that lets you inject any dependencies that it had. You can then inject Mock, Fakes, etc, and validate that the code your refactored out works as expected.

You've now added tests and refactored your code to be more maintainable. A 2 for 1 punch.

GFK_of_xmaspast
There's a huge spectrum from 'no tests at all' to 'tdd'. Spend a day setting up jenkins, and another day writing a minimal test suite to run on it, and then spend a little bit of time each day building out your test suite, and it'll add up.
blooberr
Always easier to start as an individual. I managed to retrain myself over the years from being a cowboy coder.

Since I'm one of the lead developers, I just started practicing what I preached. Every new system I build has unit tests, and every time I integrate with a legacy system or another system someone works on, I write tests for it.

I also work with that engineer to see if they need to add tests on their end.

Anytime something written in the cowboy days in production breaks, I check if I should write a test. (Normally I need to.)

This way it spread "virally" from me.

For mass adoption among the team, try to get your test workflow down so it's easy to explain and pickup.