Hey,
Would it make sense not to pull the apps that get built against #head
revision (unless the goal is to test the apps themselves) and
preferably just pull the code line it self @ #head revision? (follow
up on this in next paragraph) And also, I don't know where things
stand wrt bug tracking, but an important consideration are the bug
fixes ("does this build contain the fix for Bug X?"). Typically when
bugs get resolved/closed, they get verified on a clean slate, then
once validated & blessed (or rejected), the fix can be made public.
I think the process is pretty close to what Thadeus mentioned, but
would add the integration to bug tracking (this data is usually made
part of the release notes specifically instead of a description typed
in @ commit time). if the desire is automation (smoke tests) that I
would store the raw data of the "generic app" in some dedicated
tables, then re-populate the all-encompassing app with current data.
By always grabbing latest_row, you keep the previous data for the
previous build/release intact and in the correct place (so you don't
need to change the test process from release to release, and you have
the the build process insert a new set of records @ build time
referencing the current build. With this, you also have
reproducibility if needed.
Last point, and I know I am persistently annoying with this, but
mercurial, IMHO, sucks, sucks a lot. Personally I would use nothing
less then the best out there, Perforce, specially if considering
automated testing (again IMHO, but at least a fairly well supported
statement :)). web2py is Open source, Perforce does give additional
user licenses to open source projects (I'm sure Massimo would only
need to make the request (which is online @ perforce .com btw). I
mention that here because, good testing processes should be well
integrated to source control. and for the web2py user, offering time
for testing, a local instance of the perforce server can be installed,
absolutely free of charge (with a max of 2 user licenses per server -
more than enough for "remote workers" who can very easily keep in sync
with the "main web2py" server (I work from home (Quebec, Canada), work
for an American based company (HQ in Sunnyvale) - and that is how I do
my work, with my local p4D. works like a charm). Anyways, enough of
that, just thought I'd find another reason to slide that in ;)
regards,
Mart :)
On Oct 30, 2:58 pm, Luther Goh Lu Feng <elf...@yahoo.com> wrote:
> It is reasonable to suggest a universal test app that will assist in
> the quality assurance of web2py. But I wonder if this will always have
> 100% test coverage, given that bugs may appear even when writing test
> cases. This is still a good idea compared to not having a test suite.
>
> However, I think I would have a greater sense of security if I am able
> to test the apps I have written against the nightly/trunk build.
>
> On Oct 31, 1:46 am, Thadeus Burgess <thade...@thadeusb.com> wrote:
>
> > Where should the list of apps come from? I think this is the biggest
> > question.
>
> > --
> > Thadeus
>
> > On Sat, Oct 30, 2010 at 12:46 PM, Thadeus Burgess
> > <thade...@thadeusb.com>wrote:
>
> > > Someone writes a script to automate the process. Have a list of apps that
> > > we want to be sure are tested and working. The script will download web2py
> > > testing, copy the apps to the downloaded version, fire a process fork to
> > > start that web2py, use urllib or httplib to navigate to each of the apps
> > > pages to verify that things are working. If a response code of 500 is ever
> > > received then go get the error ticket and store it somewhere central
> > > including which app it came from.
>
> > > --
> > > Thadeus
>
> > > On Sat, Oct 30, 2010 at 9:25 AM, Luther Goh Lu Feng
> > > <elf...@yahoo.com>wrote:
>
> > >> On Oct 30, 7:05 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
> > >> > Normally it goes to the nightly build, perhaps not exactly the latest
> > >> > but something very close. The bug in question has been there for about
> > >> > one week. The problem is that nobody tests the nightly build.
>
> > >> > Massimo
>
> > >> I would love to have a way to test non stable builds easily with my
> > >> existing apps. How does one do so besides downloading the trunk/
> > >> nightly build, and then exporting the apps from stable web2py and then
> > >> import to the trunk/nightly web2py?
>
>
