

Why to engage into using Automatic Testing - ipedrazas
https://cookingsource.wordpress.com/2015/02/26/why-to-engage-into-using-automatic-testing/

======
pekk
If you are hired to write code, that's the contract; your job IS to write
code. Just like a plumber's job isn't to solve problems in general, just the
problems involving plumbing, and that's what makes him a plumber instead of
something else. Otherwise, there is no reason why we would call them plumbers,
why they would get specifically educated in plumbing, and bring a plumber's
toolbox. You don't call the plumber when you want a sandwich or a car repair.
A plumber who lets clients jerk him around by having him make them sandwiches
or answer their phones doesn't know his business.

If you are a plumber, please don't tell me that you offer solutions. Please
tell me you are a plumber so I don't have to get confused about what it is you
are actually offering.

~~~
mattnewton
I don't think this analogy is useful. I think understanding the why is
important. The plumber knows why you want running water, has seen many homes
with water systems similar to yours, and almost certainly owns a home himself.
But introducing software into someone else's business has no such guarantee of
familiarity. There has to be a discovery process, where you choose between
several ways to fulfill the need, with a much larger problem space than home
water systems. In my experience, a large part of software is automating
processes, and I can't imagine replacing a process properly without
understanding why it is done in the first place. Business owners can
understand a problem at a high enough level to hire people to solve it, but
software engineers in that position have to understand a problem so well that
they can describe it to machines who will take every step at face value,
executing it unthinkingly. Encoding a bit of the why something is being done,
even if it's just in manual tests of the software, has been crucial for that
software to do the job properly in my (limited) experience.

I'm not being jerked-around being told to make sandwiches. I'm being told, the
water-operated sandwich making machine is too slow/doesnt work properly. I
might just as easily recommend a sandwich catering service, or pick up a
manual on building fancy electric sandwich makers, as repair/enhance the water
pipes.

Disclaimer: I'm a young software engineer who, perhaps naively thinks I will
always be able to join interesting projects and learn new things while being
treated like a partner instead of a technician. This has been my experience so
far, but perhaps you reach a point where, having specialized, you churn out
the same solution for company after company in a niche for efficiency reasons.

------
msoad
In my experience unit testing has less value than end-to-end testing. Unit
tests rarely break and the reasons it break is not something that you couldn't
guess. In contrast end-to-end tests fail with a big surprise! I always enjoy
seeing my end-to-end tests catching errors that I would never ever thought of.

The down side of end-to-end tests is that it's slow to develop and slow to
run. Because in many cases, end-to-end tests should be sequential and involves
network calls and browser rendering. In general it's worth it.

~~~
mattnewton
I often suffered from that problem with unit tests - if you thought of writing
the test, you could have written that case into your code, making it only
really useful for regression testing. It doesn't help you discover bugs that
are there that you didn't think of. Integration testing helps with that
because you test multiple parts together, which is hard to hold in your head
and chances are you'll find problems you hadn't thought of while programming.
But failing integrations tests can be tricky to diagnose the root problem,
especially compared to unit tests, and require a lot of code to be written or
stubbed before they can be used.

So, I've been trying to adopt "property" based testing where you test
invariants of the output with pseudorandom inputs, a-la quick check in
haskell. Big shoutout to
[http://jsverify.github.io/#jsverify](http://jsverify.github.io/#jsverify) :)

While it can certainly be hard to apply to problems or find some useful
invariants, It's been enormously successful in finding bugs I didn't think of,
and shrinking is an elegant solution to making failures more easily
diagnosable.

------
DanWaterworth
Modern software development has always struck me as trying to optimize the
wrong thing. It tries to make change easy, but changing things is never easy.
Just throw away your code and start again. If this a lot of effort, its
probably doing too much.

