
Ask HN: How can a successful startup adopt a strong testing workflow? - notdonspaulding
We&#x27;re a small group of &quot;cowboy coders&quot; who tend to let our end users be our test suite.  We&#x27;ve gotten pretty far with this, but lately we&#x27;ve seen the ill effects of not testing.  We can see that in order to grow we&#x27;re going to need to bolster our workflow with a real testing methodology.  But while we&#x27;re proficient at several languages, we didn&#x27;t &quot;grow up with&quot; a test-driven culture.<p>Has anyone successfully retrained themselves from a code-first, test-maybe mindset to a code-whenever, test-always mindset?<p>Is it easier to do this as individuals or as a team?<p>Is there any advice you would give to someone who knows how to code but doesn&#x27;t know how to test?
======
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.

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

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

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

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

