@Chris
I have thought about what you wrote about journals requiring authors to submit tests as part of papers. I don’t think it is overkill, wetlab biologists have to be very rigorous about what controls they use, so why shouldn’t bioinformatician’s have to do the sane? Most modern testing software produces readable results, that for example a reviewer could quickly cast their eye over.

@Paradoxus
I agree that going through your code can be repetitive and boring, so in no way do I advocate this. In fact, I think in programming if something is hard work there is usually already an existing solution to make it easier. For example unit testing is meant to run quickly and easily every time you want to make sure that your program is working. This is usually better tthat adding print statements through out your code. Worth a look perhaps?

@Andy
I agree that you should be prepared for unexpected results, and I hope the point I was trying to make was that if you’re sure that your code has no bugs in, then you can be more confident in the results you have produced. Especially in the case where the results challenge previous research. I’m not advocating routines that conform, rather that they do what you have written them to do.

@Pedro
I am exactly the same, most of the time I write posts of what I think I should be doing rather than what I am actually doing.

1) Testing is good. In fact, testing is essential. But - particularly in bioinformatics - it is equally important that you understand why your test inputs should produce your test outputs. Writing code to produce predictable results is required where the process is well understood and validated, but if there is the potential for uncertainty every concept needs to be challenged. One should never be afraid to come up with a result that differs from the expected. If you read the boscoh post fully, you can see that it took a long time for the results to be questioned because no-one believed in their results enough to challenge the previous ones. If we were all coding routines that had to conform with the conventional wisdom, we would never advance.

2) The really important thing is to be *auditable*. Version control is a non-negotiable. Accurate records of which version of the code was run on what date with what input is, likewise, something that is essential. Checksum everything. Record everything. Dare to challenge, but be prepared to be challenged is the essential maxim.

Another issue is the program you use which was written and published by someone else. If (just an imaginary scenario) a well known program is found to be faulty, what will the consequence be?

It also takes time to go through all of your code again and again. Debugging is never ending. For my analysis, first I make sure the core code (analysis/model) is correct, then I spent more time focusing on the parsing the correct format of the data.