3 ms·

Ask HN: How to learn how to test code

9 points by czzarr 15y ago

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 15y ago
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 15y ago
  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.
latch 15y ago
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 15y ago
  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 15y ago
    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).
narag 15y ago
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.
pasbesoin 15y ago
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.)

9 points by czzarr 15y ago

TMK 15y ago

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 15y ago
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.

latch 15y ago

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 15y ago
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 15y ago
  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).

narag 15y ago

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.

pasbesoin 15y ago

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