Hoowdy! I see that in the past OpenEMR had an automated PHPUnit test suite that was used up until about April of 2012 (at least that’s what it appears like from the Wiki page here - http://www.open-emr.org/wiki/index.php/Automated_Testing). I am just wondering if the project started using a different testing method or if currently we don’t really have one. Thanks for any info people can share on this.
Hi,
The project doesn’t really have one. But we are open to anybody that wants to work on one. Currently have those test scripts you mentioned above in the Tests directory.
-brady OpenEMR
Brady - Thanks for the reply. Will start looking into it. In my day job I
am a Family Physician but I used to be (for about 9+ years) a software
developer who worked exclusively on web based systems.
Hi,
The project doesn’t really have one. But we are to anybody that wants to
work on one. Currently also have those test scripts you mentioned above in
the Tests directory.
-brady
OpenEMR http://www.open-emr.org/
In looking to revive this it’s a bit more complicated than first
anticipated and I wanted some input:
Since the current small number of tests has been dormant for over 2
years I will most likely remove what we have and start from scratch. Seems
easier that way since the Installer testing class alone is causing quite a
problem in getting to work correctly. Any objections?
In terms of dependencies (i.e. requiring PHPUnit) I currently develop on
Unbuntu and there is a system package that will install PHPUnit. Do you
recommend that we actually grab a particular version of the library and
place in the code set, or is it ok for me to just use the current version
on Unbuntu? My preference is to include as little dependencies as possible
in the git hub repo. Keeps the code smaller.
In terms of longer term development is the project headed towards using
a more ‘composer’-esque method to dependency control? I aks only in
reference to the whole ‘bootstraping’ aspect for libraries … it’s nicely
handled using composer setups but in our current code base it looks a bit
convoluted (maybe I just don’t understand it yet …).
More later. I was able to get a small set of tests working with code
coverage reports but then I broke the entire system (installer and all) and
it was easier to just start from scratch.
Brady - Thanks for the reply. Will start looking into it. In my day job I
am a Family Physician but I used to be (for about 9+ years) a software
developer who worked exclusively on web based systems.
The project doesn’t really have one. But we are to anybody that wants to
work on one. Currently also have those test scripts you mentioned above in
the Tests directory.
-brady
OpenEMR http://www.open-emr.org/
Bit of history regarding installer class, I think there is likely a scope issue somewhere that is breaking that for phpunit. The author whom created the phpunit testing actually even built that very nice installer class to allow the phpunit testing. But then it broke at some point. If you restart from scratch won’t you still want to test the installation steps? Rather than throw things out can you leave them there, but not use them for now in your testing? Or does the existence of them break things?
Agree not to include phpunit in OpenEMR. Makes sense to keep the testing scripts (as is now there) in the codebase, but agree not to include the phpunit library itself. Ideally, as was done before, somebody will set up a server that runs builds of OpenEMR automatically via phpunit.
You are not incorrect in seeing codebase as rather convoluted.