

Ask HN: Tutorial teaching a team new to testing and CI how to get started? - jacquesm

A company I work with is in dire straits. They have been delivered a bunch of barely functional very unstable code for a ridiculous amount of money. They have a mixture of in-house people and hired guns that together have built this totally over-the-top solution. I&#x27;m coaching them - hands off for now - on getting things back under control.<p>One of their biggest flaws - besides the over-engineering - is that they have absolutely atrocious testing. I want them to make a start with and eventually move over completely to automated testing. But when I figured I&#x27;d send them a couple of links to get them on their way I realized that there are a lot of crappy tutorials but not a single one that stands out as <i>the</i> reference for automated testing for distributed teams.<p>Is there anybody on HN that can point at a reference for a start-to-finish approach to automated testing?<p>Pre-emptive thanks for giving this your time.
======
jamesbrewer
This isn't what you've asked for, but I'd like to offer some unsolicited
advice, if I may.

When you are selling high-priced products to consumers you have to sell an
idea first and your product second. Let me offer an example.

I used to sell beds. Selling expensive beds to your every day person is really
hard, because they are so expensive. Who is going to spend $7,500 for a luxury
Tempur Pedic when they could get cheap mattresses from Big Co for $300?
Eventually, I gave up trying to sell beds. It was just a waste of time because
nobody every bought them.

Then something interesting happened: somebody gave me the advice I gave you.

You see, when you are selling something expensive, you can't just push the
product. You have to sell your customer on the experience.

How did I apply this to mattress sales? It was easy!

Did you realize that you spend approximately 33 percent of your life sleeping?
Sleeping is your body's way of regenerating itself. It's the biological
equivalent of turning off your laptop when it starts to overheat. It gives
your muscles and tissue time to rebuild themselves. It gives your brain time
to digest everything you've learned that day.

A good set of mattresses will last you 20 years. With that said, very few
people go so long without replacing their bed. In reality, a bed will last
about 10 years; less if the customer has a lot of money or moves frequently.
But let's assume a 10 year lifespan for your new $7,500 bed.

Over ten years, that bed will cost you $2.05/day.

Now is $7,500 a lot up-front? Absolutely. But like anything else of high
quality, this bed is an investment. And what an investment it is. I will bet
you that a luxury Tempur Pedic will give you a better ROI than most stock
traders who have been in the biz for 20 years get.

How?

Simple. Better sleep = better productivity. If you got a great night sleep
every single night, do you think you could turn that extra productivity into
$10 dollars each day? I know I could! If I were productive for one extra hour
each day, I would make an extra $100 a day.

Assuming you make an extra $10 a day from your new found productivity, this
bed will pay for itself five times over throughout its lifespan.

And so on and so on.

You see, I'm no longer selling a bed. What I'm selling is a complete
experience, an investment and a new way of life. $7,500 doesn't seem so bad
when it makes your life better for the next 10 years now does it?

What's the point of my rambling?

You need to avoid selling your coworkers on testing. Very few people like
testing and the only sure-fire way to make somebody do something is to make
them WANT to do it.

Instead, try selling them on how their lives will improve if they increase the
quality of their software. Show them how they will benefit from shorter
release cycles, fewer bugs, higher quality code, etc. Show your coworkers the
benefit of taking the time to correctly architect a solution before they start
implementing it. How does taking the time to learn and correctly use the tools
at their disposal benefit THEM?

Will this be difficult? Absolutely. People don't want to change. Your job is
to make them WANT to be better. There is simply no other way to accomplish
your goal with any lasting impact. Sell your team on the complete experience,
the investment and the new way of life.

Hope my two cents helps. :)

~~~
joshschreuder
This reminds me of a TED talk I watched last night
([http://www.ted.com/talks/simon_sinek_how_great_leaders_inspi...](http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action/transcript?language=en))

"People don't buy what you do, they buy why you do it". You sell the bed not
based on the quality of the materials so much as the improvement that it gives
to their life.

------
clueless123
I do exactly that as a job, I teach modern development techniques to
established software shops. The way I present it, is to teach good development
habits by using good development tools.

1\. Before _anything_ start with version control and how to use it
effectively. With out this step you got nothing.

2\. Collaboration. Choose a project management tool (Jira or the like) and
show them how to use it effectively. Show them how developers use it to keep
PHB & managers honest.

3\. Continuous Integration. Choose a CI of your choice, set it up, get it
working for them, get them addicted to the time/work savings. (I use Jenkins,
but now there are better ones)

4\. Testing. Teach them _why_ testing is good, help them implementing the
testing framework (On the CI) and help institute it as a 1st level part of the
development process.

My style, is to never give them "more work", but to show them how each step
_saves_ them work and time.

Regards

~~~
jamesbrewer
I'm interested in hearing more about your work! Would you mind trading a few
emails? My email is in my profile if you're interested. :)

------
zachrose
I work mainly with front-end JavaScript developers, who generally speaking got
into programming through HTML and CSS and see testing as something someone
else does after they've built the thing. (Which also perfectly describes me up
until a year ago.)

I don't have a reference for start-to-finish automated testing, but I like the
way in which Justin Searles explains the difficulty of such a thing here:
[http://blog.testdouble.com/posts/2014-01-25-the-failures-
of-...](http://blog.testdouble.com/posts/2014-01-25-the-failures-of-intro-to-
tdd.html)

I gave a brief presentation about testing a few months ago and felt like it
didn't really connect. I think it's genuinely hard to break the preconceptions
about testing, and also there's a fair amount of incidental framework and
library minutia that can be hard to isolate from the big picture ideas.

Subjective experience is a huge factor. Trying to rationally explain the
advantages or conceptual underpinnings of testing doesn't always work. (In
hindsight it didn't work for me either.) It really takes sitting down next to
somebody and walking them through a process. I've had success in showing a
test I wrote from some unit that I wanted to exist, deleting the
implementation, walking them through a re-implementation, and then passing
them the keyboard to implement another deleted implementation.

Make sure that the developers _actually experience_ a cycle of red-green-
refactor.

