From: Mark W. <ma...@rw...> - 2011-05-10 10:16:52
|
I think Unit (PHPUnit) testing would be a good way to go. If we are going to spend time testing, we may aswell spend time upfront writing the tests as once it is done it is done. The majority of the tests can then be automated. Also PHPUnit does not hvae any dependencies on other software languages unlike many of the suggestions in the stackoverflow thread. With regard to the PHP version targetting, maybe we should just say (for now) 5.x Once we have test routines in place it will make it much easier to do cross version testing. For the time being, if we all try to stick to the versions of php we currently have but with Peter running the bleeding edge version, that will give a degree of cross version testability. I also agree with Peter that we should finalise a list of updates for the next release and push them out by a particular date. If we said 1st September release is our target, that would seem reasonable to me? Mark _____________________________________________ Mob: 07725 695178 Email: ma...@rw... On 10/05/2011 04:28, Peter Lazarus wrote: > The PHP support issue suggests we consider a couple of other issues. > These issues are a) some form of testing b) some feature lists and versions. > > If we are going to write and release software versions then some test > process and check-off process is needed. > > We are all working away to change things, but it is about time I think > to set some goals which we can focus on. A set of goals also allows some > software features to be released. Otherwise I feel we will be coding > until next year. If we agree on some feature based goals, without target > dates, then that gives us a way forward. The reason I said no target > dates is we are all volunteers with our lives to lead, so working toward > date targets will be difficult. > > So I suggest we compile a list of features we are working on, along with > their state of achievement. From that list we can aim to complete our > features and get them out there. I would suggest we keep our feature > list and release targets on the developer list only, and not publish it. > Then there is no pressure to get things released. > > Here is a short paper discussing some of the issues in software release > related to SubVersion 1.5. > http://www.google.com.au/url?sa=t&source=web&cd=3&ved=0CDEQFjAC&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.143.4757%26rep%3Drep1%26type%3Dpdf&ei=-azITeq1BoTsuAP-ncjcBQ&usg=AFQjCNFzQFzKlcwgp24ouyLd8wl3jAiA7w > > For testing, we could use some open source web testing tools. However > these tools would require a fair bit of work to set up. Here is an > article on three of them: > http://www.infoworld.com/d/architecture/three-open-source-web-service-testing-tools-get-high-marks-995?page=0,0 > > And here are comments on even more tools: > http://stackoverflow.com/questions/79733/best-automated-testing-tool-for-web-applications > > Alternatively, we could create a simple one page list of tests that a > release needs to achieve before its release. > > Peter > > ------------------------------------------------------------------------------ > Achieve unprecedented app performance and reliability > What every C/C++ and Fortran developer should know. > Learn how Intel has extended the reach of its next-generation tools > to help boost performance applications - inlcuding clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > Tsheetx-developers mailing list > Tsh...@li... > https://lists.sourceforge.net/lists/listinfo/tsheetx-developers > |