Unit tests?

[peterjc]

Some of your more technically inclined potential users would be concerned at the lack of unit tests in the repository. The provision of test data is a good first step - and could be the basis of a test suite.

Once you have a basic test script, which can return zero on success or non-zero on an error, this could be used for automated testing. If you are not already familiar with TravisCI and its excellent GitHub integration, I would suggest looking into that http://travis-ci.org/ - this would require the Linux binaries to be available as Debian/Ununtu packages, or simple to download 32bit Linux binaries.

[willpearse]

Hello,

You're quite right; unit tests are important - I certainly agree with that!

I've shied away from doing anything too formal publicly, if only because pG uses so many other programs internally, all of which are in turn changing, and many of which do not have deterministic output, that I feared too many users would run unit tests, find they were not getting the output "they were supposed to" and would be concerned.

However, if others (including yourself) feel strongly about this, I would be quite happy to incorporate some formal unit tests of the internal functions. I'll try and do so in the coming weeks, and hence won't close this issue now.

Thanks for getting back to me - I'm really grateful for feedback. Again, I'm sorry it's taken me a while to get back to you on this - somehow I didn't receive the notification of this issue, probably because I've just moved continent and things have been quite hectic with that!

Thanks again,

Will

[peterjc]

Non-deterministic output is a problem - some tools allow you to resolve this by supplying the random number generator seed at the command line, but that is a rare luxury.

Dependencies on multiple external tools with their own releases and changes is more what I would worry about as a user - perhaps clearly documented recommendations down to the point release would be enough?

[willpearse]

Thanks for getting back to me!

Indeed, random number seeds would be one way to go, where possible.

You're right to worry about external dependencies. Everything that comes shipped with phyloGenerator is actually the program itself - you can just run something like:

./requires/programme_name --version

and you'll find out what version of that program you've got. All the versions of the programs in the current release are here: http://willpearse.github.com/phyloGenerator/faq.html - though I agree I will have to do something more sensible than just put them in the FAQ when I start upgrading things.

Thanks again,

Will

[vincentdavis]

I am willing to help.

[willpearse]

Hello,

Thanks for the offer, Vincent. I'd love help working making the program better!

I think it's best if I put up the first set of unit tests, and also some basic documentation as to how the internals of phyloGenerator work. I think trying to work collaboratively on something before I've made the basics of the program easier to understand would make things extremely difficult.

Once I've got these basics up, it should be easier for us to work together.

Does that sound reasonable?

Thanks again,

Will