[squeak-dev] Re: Test Server

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: Test Server

keith1y
Alexandre Bergel wrote:

> Hi!
>
> I've been told that Keith and maybe few others are working on a test
> server.
> In a 10 minutes seaside coding session I did a small application that
> displays a result of a SUnit test.
> Is there anything like this around?
>
> Cheers,
> Alexandre

Yes... 'SUnit improved' has a TestReporter, since Jan/Feb 2007.

It is designed to be invoked from the command line on any image, and to
work headless if desired.

It generates results to files, the idea being that the progress can be
observed remotely via ftp or http.

Failures and Errors are generated in a file form that can be viewed
remotely, but selected failures/errors can be run by doiting the line of
the output file.

There is one file which has a byte written per test so that you can see
progress remotely just by looking at the file size in a web /dir/ftp
browser.

There are also custom icons for apache to show pass/fail/errors etc
though I am not sure where I have put them.

===

Please please please, you pharo guys, actually look at SUnit improved,
before doing other things with SUnit, I put a lot of effort in to it,
over the past 2 years.

The latest suite defining and building architecture is really cool. It
uses less code than the old system and is better factored to achieve
more. For those of us that are interested in developing packages that
everyone can use, we need a coherant story accross the board so that we
can write tests and flag which images we expect them to work in. 'SUnit
improved' has this in TestCaseVersioned.

ClassClonerTestResource is another case in point, I wrote it so that we
can test the class side of DateAndTime, etc, but still the wheel gets
reinvented again and again.

A really useful addition which I have been planning for ages, but you
would be welcome to have a go at, would be excellent if SSpec specs
could be run in the same ui.

cheers

Keith

p.s. Bob the Builder update to follow

Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Bob

keith1y
Dear All,

Bob is slowly taking shape, I am perhaps a day away from alpha, but I
don't have much spare time this week, so I expect that this will not be
available until next week.

If you would like to contribute, I am hanging around in squeak irc most
(uk) evenings.

some docs follow,

cheers

Keith

....

=======
*
Bob the Builder*

*/Your Build is defined as a Class/*

To add your own 'Build' process to Bob, create a subclass of BobBuild,
with your process defined as a SakeTask returned from the class method
#build. When Bob starts his work in BobBuild-c-#taskMain, he collects
all of these tasks, and sorts them according to their dependencies.

/*Your build can depend upon other builds*/

So your build can specify which other builds it depends upon, for example:

BobBuildMyWebServer-#build

^ self define: [ :task |
    task dependsOn: { BobBuildSeasideOneClick build }.

    .... ... ... ].

/*Repositories are watched and builds run when changes are spotted*/

Sake-Scheduler is used to run periodic tasks. These tasks can do many
useful things, as well as running #taskMain. Scheduled tasks are used to:
 
1. Periodically collect data that either Bob/users may need in their
work (e.g. BobPeriodicallyReadMantis )
2. Periodically update the Bob server image with the latest code from
contributors (e.g. BobPeriodicallyWatchRepositories )

You can add your own periodic tasks by subclassing ScheduledTask,
however some tasks are designed to be extended, by adding (extension)
instance methods.

e.g. BobPeriodicallyWatchRepositories-#taskWatchPackages (watches the
squeaksource Packages repository for updates)
if you wish to invoke bob following an update to your repository this
example shows how.

BobPeriodicallyWatchRepositories >> #taskWatchTasks

^ SakeTask     checkUrl: 'http://www.squeaksource.com/Tasks/feed.rss'
            onChanged: [ Installer sake install: 'Tasks'.
                         BobBuild taskMain run. ].
   
/*Configuration*/

Your build process 'task' #build is defined on the class side of your Build
class. If your task has a number of "const" parameters that configure
the task, these should also be defined on the class side. For example,
the location of a working directory would be returned from #configWorkingDir

/*Metadata - build numbers etc*/

The metadata for each Build task is specified on the instance side of
the class, e.g. #build0001, #build0002.
Your task definition in #build automatically uses the most recent
metadata method.

example metadata:

MyBuild>>#build0001

    info name: 'Squeak3.11-basic'.
    info moniker: '311'.
    info codeName: 'Kipper'.
    info by: 'kph'.
    info image: 'bzr://bzr.warwick.st/squeak/3.10'.
    info candidate: false.
    info release: false.
    info overwrite: true.
    info comment: 'testing'.
       

/*Only build if necessary*/

It is very important that your build only runs when absolutely
necessary. If your build is manually invoked by an increment in build
number (i.e. info overwrite: false) then the existence of the output
directory with that build number is enough to determine that the build
has already been run.

If your build is automatically invoked by updates to particular
repositories, then the versions of those packages need to be recorded in
the metadata. The metadata is written to a file in the output directory.
Subsequent builds should compare the current metadata with that in the
file to see whether the build needs to be re-run.

If your build is a derivative of a released product, then you only need
to build if the dependant has #info release = true.



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Test Server

stephane ducasse
In reply to this post by keith1y
Thanks for the update.
Now I cannot do everything. So other people should also have a look at  
your code and give feedback
so that we integrate it or at least give you feedbakc.
The refactoring of installer that did matthew is great.
Now it would be good if you/he could take into account the remark of  
lukas about the different instances lying around.

Stef


On Oct 27, 2008, at 10:30 PM, Keith Hodges wrote:

> Alexandre Bergel wrote:
>> Hi!
>>
>> I've been told that Keith and maybe few others are working on a test
>> server.
>> In a 10 minutes seaside coding session I did a small application that
>> displays a result of a SUnit test.
>> Is there anything like this around?
>>
>> Cheers,
>> Alexandre
>
> Yes... 'SUnit improved' has a TestReporter, since Jan/Feb 2007.
>
> It is designed to be invoked from the command line on any image, and  
> to
> work headless if desired.
>
> It generates results to files, the idea being that the progress can be
> observed remotely via ftp or http.
>
> Failures and Errors are generated in a file form that can be viewed
> remotely, but selected failures/errors can be run by doiting the  
> line of
> the output file.
>
> There is one file which has a byte written per test so that you can  
> see
> progress remotely just by looking at the file size in a web /dir/ftp
> browser.
>
> There are also custom icons for apache to show pass/fail/errors etc
> though I am not sure where I have put them.
>
> ===
>
> Please please please, you pharo guys, actually look at SUnit improved,
> before doing other things with SUnit, I put a lot of effort in to it,
> over the past 2 years.
>
> The latest suite defining and building architecture is really cool. It
> uses less code than the old system and is better factored to achieve
> more. For those of us that are interested in developing packages that
> everyone can use, we need a coherant story accross the board so that  
> we
> can write tests and flag which images we expect them to work in.  
> 'SUnit
> improved' has this in TestCaseVersioned.
>
> ClassClonerTestResource is another case in point, I wrote it so that  
> we
> can test the class side of DateAndTime, etc, but still the wheel gets
> reinvented again and again.
>
> A really useful addition which I have been planning for ages, but you
> would be welcome to have a go at, would be excellent if SSpec specs
> could be run in the same ui.
>
> cheers
>
> Keith
>
> p.s. Bob the Builder update to follow
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Test Server

keith1y
stephane ducasse wrote:
> Thanks for the update.
> Now I cannot do everything. So other people should also have a look at
> your code and give feedback
> so that we integrate it or at least give you feedbakc.
> The refactoring of installer that did matthew is great.
> Now it would be good if you/he could take into account the remark of
> lukas about the different instances lying around.
>
> Stef
All sorted as far as I know

Keith