Hacker News Reader

Comment by mcrider | Hacker News Reader

Testing. I'm a very experienced programmer, and I have written plenty of unit tests -- but I've never worked in a place with a good testing culture and I've always struggled to develop a high level mentality of how and why I should be testing my software. When should I write a test for something and what is the best way to go about it? Does my code have to be more 'test friendly'? TDD seems very appealing to me as a way to outline my software before I 'dive in' but its hard for me to rationalize spending the extra time on building out the testing framework.

View on HN

I struggle with this as well. I wouldn't say I'm very experienced, but I've been around the block for awhile. I use TDD successfully, but I always have problems with edge cases. I think of and try to guard against edge cases, but I feel like testing in practice is really just preventing regressions for test cases. Most the bugs I actually see in my software are of things I didn't think about (obviously).

Sometimes I wonder if I should only write a test when something unexpected happens (e.g. user has a bug report) instead of wasting time writing tests on the front end for core features and obvious edge cases.

I mostly work on scientific software, btw.

My first job involved writing developing test suites for a platform (with few software layers). Each layer again had many levels of tests - unit(api), component(state machines), integration(2 layers), alpha, finally-a-swiss-knife test script. Doing at that time - I disliked my job (may be coz we did scripting in an obscure language). It was ridiculous the amount of effort we spent to develop whole suite. Level of tests was so stringent may be a healthcare product or aircraft software could only be more detailed or comprehensive.

As this complex product evolved at rapid pace - one of the key differentiating factors of this product and others were time to market and product reliability - benefit reaped was many folds from test suite. Many LOB directors realised that efficiency of our platform had to do with test suites. If I've to run a successful company - I would heavily rely on such a test suite.

Having said that - its hard to write detailed TDD in early stage startups. I didn't write TDD at my last startup work but I had a swiss-army-script to test. In this case, reliability of software is on a developer who developed it. But once a component is proven and it goes as core software of your startup - it should be baked with test suite.

Same here. I'm working on a software project (java) for years and I wrote zero testing code. The problem is that my java code is straightforward and pretty much a thin layer between complex slq-magic and external API's. Yes, I could test this 20% of the application written in java, but it would take a lot of time and I don't expect much gain from it. On the other hand it is hard to test the behaviour of an external API. Most of the business logic resides in sql-statements. Hence it would be much more valueable to test them. But the only idea I had how to test sql statements is to automatically recreate the whole database (which is big) on a test-server for each test-case. Is there a framework for this?

I don't follow TDD strictly, but I still think testing is important. I mostly see tests as help for future programmers (which includes the original authors), kind of like documentation. It's a rigid description of how the system should operate and therefore is usually helpful for refactoring or extending old code. I also don't doubt that many people go years without seeing utility in writing lots of tests. From my experience there's a lot of factors that go into how many tests you write before getting diminishing returns. Some off the top of my head: static v dynamically compiled lang, functional v procedural lang, age of project, etc.

Reply on news.ycombinator.com