My concern is more around the return on investment and not with the learning curve of Selenium because I’m reasonably okay with Selenium. As I said before, it took a long time for me to test a very basic happy path of new patient encounter… with the complexities of adding in the other scenarios given all of the iframes, pop-up windows, and lack of CSS selectors to uniquely identify certain elements with, I don’t think I can justify the time it will take to implement the automation (https://xkcd.com/1319/).
At this point, I think putting together a mature manual test suite that a group of volunteers can run through every few months before releases would be ideal. These tests can be maintained over time, used by developers as a reference point during the refactor, and help with automation efforts should they happen in the future.
Thoughts?
In response to “Will there be any code infrastructure needed for the unit tests?” – my understand is that Robert is pushing for unit testing as a requirement with the refactor. I am very much in favor of this (I’m biased… the projects I’ve been on with unit tests tend to be much more stable and easy to maintain). We can use PHPUnit and also set up coverage that can be checked at the time of code review.
I am ambivalent about the value of automated testing for this project at this stage. Bulk of contributions I have seen in recent past are after someone put the code through their production. Further, compared to commercial applications there are very few places where multiple entities are maintained (vs. displayed) together. So suite of unit tests will help but is not crucial for maintenance.
The approach changes if a major rewrite is attempted. In that case that project should pay the price of developing automated testing as they will have immediate returns throughout their development cycle.
In a resource constrained world, (potential) ROI trumps as a deciding factor.
Highly recommended. It talks about recent trends in PHP programming, new features in the language, The Framework Interop Group and its standards recommendations, frameworks, components and many other topics.
It suggests using standards-compliant components instead of committing to a framework. But also makes the point that “not all frameworks are bad” and singles out Symfony as one of the better ones.
It does not mention Zend Framework. As best I can tell, ZF has about 5% of the framework market and has a reputation for being hard to learn. It’s in the project because ZH Services likes it and used it for some of their contributions.
“Hard to learn” would, I think, be very bad for this project which benefits from a fairly diverse community of developers. A component-driven approach seems right to me. But again, those who actually write code have the biggest say in how it’s done.
By the way the author of the above-mentioned book is also co-maintainer of http://www.phptherightway.com/ so you can get updated summaries of much of the same info there.
After much research myself, this is the same conclusion that I have come too. Rather than working towards adapting an “MVC Framework” we need to look at refactoring the code into modern OOP style php.
There is also the idea of “decoupling” your code from frameworks enough that you can then change to the latest and greatest framework when needed.
I think moving towards V5 of openemr we need to look at this more.
I’d like to get things moving here with my understanding of the general consensus here and, of course, inject some of my own opinions for the purposes of expediting things a bit (it’s typically hard to get a group of developers to completely agree on technology decisions… best shot is to compromise on a stable, sensible strategy and run). I’d like to note that the most important takeaways are: a) for folks to focus on the end goal and* b)* to understand this work will be accomplished in a very fragmentary way that requires a very organized and enthusiastic approach.
With this said, I’ve heavily updated the Modernization Roadmap with 3 project teams that can work in parallel and can centrally track their progress.
We’ll need more than just myself, Robert, and Brady to tackle these 3 big projects though. Anyone else want to volunteer? Have any friends that may be interested in helping out?
@All: Perhaps my approach with the teams is too rigid. I’ve updated the Modernization Roadmap page to not include the teams. The page just simply lists the roadmap and has links to the underlying projects (manual tests, refactor, new ui) that folks can organically help out with: http://open-emr.org/wiki/index.php/Modernization_Roadmap.
@Robert: Please see the first item I put on the codebase refactor project page: http://open-emr.org/wiki/index.php/Codebase_Refactor - is this code worth a look for inspiration or it is has it become sufficiently stale? I haven’t taken too close of a look and I realize it’s not MVC but wanted to double check before moving on. Let me know.
