

Ask HN: How to learn how to test code - czzarr

I work at a company when nobody ever tests/tested anything. Therefore our software is very buggy. I want to change things, where do I start ?
I would appreciate comments about test-driven development and unit tests and where to learn about these and get started with testing.
======
TMK
One thing, run your code through debugger after successful compilation with
warnings set as errors. If your code does not compile when the warnings are
set as errors, then fix them. Afterwards run your code in a debugger. Do this
as often as you can.

Unit testing is checking that function returns the correct data in different
scenarios. This can be easily done with unit testing functions for your
language.

For example C preprocessor macros I use for unit testing.

#define equal(a,b) printf("%X == %X = %s\n", a, b, (a == b) ? "true" :
"false");

#define diff(a,b) printf("%X != %X = %s\n", a, b, (a != b) ? "true" :
"false");

~~~
swordswinger12
I don't know if preprocessor macros are the best way to unit test C. There are
fully featured (and free) unit testing suites out there for c/c++, Boost comes
immediately to mind. No need to re-invent the wheel, especially not when there
is customer money on the line.

------
narag
A little practical advice that you can hopefully apply quickly: encapsulation.
Provided your software is composed of modules, try to reduce to a minimum the
interaction between modules. Once you have minimal and clearly defined
interfaces, it will be easier to design a test strategy.

------
latch
A bit more insight might be helpful...I've found that effective testing
differs some based on type of work and technology. For example, the way you
test a game is different than a website. And the way you test Rails is
different than how you test Java.

~~~
czzarr
we build web apps in a proprietary language (yeah I know this is the core of
our problem but it's not something we can change right now)

~~~
latch
Ya, that's a problem. Still don't know enough to say, but if I had to guess,
I'd say your core problem is cultural/people, and until that changes, there's
nothing you can "learn" to improve.

On a technical level, if your language doesn't support things like inversion
of control (in one form or another) and reflection/proxying (or a dynamic
runtime), it's going to be an uphill battle to write effective, non-brittle
unit tests. Therefore, maybe end-to-end integration tests might be a better
fit (for which, I'm no expert).

------
pasbesoin
Read around a lot. There are plenty of stories out there about how/when things
have gone wrong. Then start asking yourself whether you could have the same or
a similar problem.

 _Similar_. Don't look for a "plug-and-chug" formula. Understand what went
wrong and why. When you look at your own work, those lessons will be floating
around in your subconscious and sometimes surface into conscious concerns.

Have a deep-seated concern about "getting it right". If you don't have this,
you won't "make" yourself do the rest. You need the interest in getting things
right, as a precursor.

(I've seen a lot of QA that reduces to "pushing buttons in return for a
paycheck". This level of involvement won't get you too far -- although it is,
or was a few years ago, quite prevalent.)

