I propose the people most competent and interested in this subject form a team to work on it. Call for help, setup a mailing list and an IRC channel. I will be happy to use/incorporate a testing suite.
Massimo On Aug 22, 10:57 am, Paul Gerrard <p...@gerrardconsulting.com> wrote: > Hi All, > > Like Mart - I'd better declare an interest and some knowledge in this > area. > > My company is Gerrard Consulting (www.gerrardconsulting.com) I'm very > active in the UK and European testing community and have written a > couple of books, done lots of conference work, host the UK Test > Management Forum (uktmf.com) etc. etc. I am using Web2py to create a > test management tool that we will use to support our testing services. > (It's mainly for test design and record keeping in large software > projects, rather than test execution). So I am very interested in a > rock-solid Web2py as my company will depend on it :O) > > Right now, I'm full-on writing code and testing as we launch in mid- > September. But I will be creating a performance/stress test for our > app as we'll be making a free subset of the functionality available on > our servers.Obviously scalability is a concenr for us. I'll probably > use The Grinder (http://grinder.sourceforge.net/) to stage these > tests, but that won't be for 5-7 weeks I think. > > I'd be very interested in collaborating to create some form of test > automation regime for the Web2py infrastructure and applications using > either available tools or maybe writing our own framework. (I'm > looking to build an interface from my tool to things like Fit/Fitnesse > (or replace them) and Selenium as I focus very much on acceptance > testing). This might be the subject of another thread, perhaps. > > Sorry for the length of this, but I thought I should declare my hand > and support for a 'stabilisation period'. > > Paul. > > On Aug 22, 2:25 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > Dear Mart, > > Your help is very much appreciated. In particular because I am not > > very knowledgeable about this aspect. > > I am old fashion and for me the less I use mercurial the better. For > > example I keep one single branch of web2py. I simply apply patches, > > test them, and either revert or commit. This model has worked well > > for me and I would not like to change it. > > > I too am uneasy with the idea of freezing but not with the idea of a > > testing period. How do you suggest we proceed? > > > Massimo > > > On Aug 22, 4:30 am, mart <msenecal...@gmail.com> wrote: > > > > Good evening all, > > > > I hope no one takes offense by me jumping in, but I couldn't help > > > myself as the thread's subject got my attention (release management is > > > what I do). If you'll allow me, I'm just curious as to the narure of > > > your current branching strategy wrt the subject of the thread? In my > > > experience, freezing a code line is rarely beneficial, least of all to > > > the release going forward. So, was wondering if finding the correct > > > branching strategy (as well as defining an appropriately well matching > > > high level root folder structure in your source CSM) would help in > > > sorting out such things as separating out and accommodating the need > > > for stability, moving forward and any iterative requirements in your > > > release cycles? (I heard someone last year year - obviously someone of > > > the newer generation - call this "the need for speed" ;) ) But > > > regardless, if at all interested I'd be happy to do my part and help > > > out in any way I can if such plans are being considered. BTW - I was > > > hired to revamp and restructure release management processes last > > > spring for US based company, and web2py (with some Flex pieces in it > > > for demo purposes) was what I used to to showcase and spread the word > > > about the proposed changes :) > > > > On another note: > > > I saw that some PDF libs were on there way for web2py???? Awesome! I > > > am looking forward to that! :) I made a web2py app a few weeks ago > > > (mixing the ReportLab's tool kit and Flex/iFrames) so that the kids in > > > my daughter's violin class (yeah ok, this may be a little weird, > > > but...) could generate fingerboard position markers (which are then > > > convert to printable PDF templates) so that the kids could create the > > > exact position markers for their instrument (I think she hates things > > > that are pitchy). Anyways, did not want to use LiveCycle data services > > > (with flex) for this (although it does do some good things), and even > > > though the results I got with what I used were a little ok (or most > > > probably, the problematic parts had something to do with the guy > > > writing the code :) ), generating PDF with good tooling will be great! > > > I'm already a fan! :) > > > > Thanks, > > > Mart :) > > > > On Aug 22, 1:02 am, Jason Brower <encomp...@gmail.com> wrote: > > > > > Again I think we have more pressure for testing tools. Which I agree > > > > on. > > > > BR, > > > > Jason > > > > > On Sun, 2010-08-22 at 00:32 -0400, Andrew Thompson wrote: > > > > > On 8/20/2010 4:54 PM, Phyo Arkar wrote: > > > > > > -bug-squishing-contest , > > > > > > -Stress test, Test everything , try to crash web2py etc. > > > > > > Could we build an app to act as a test harness? > > > > > > Or a script to build an app per a test case, evaluate it, then destroy > > > > > that app, loop etc. > > > > > > Turning bug reports into test cases causes regressions to be noticed > > > > > quicker I would think.- Hide quoted text - > > > - Show quoted text -
