Anton Luht wrote:
> Hello,
> 
> I know why this thread is so lazy - it's because everybody dislikes QA
> & testing :)
> 
>> OK, now let me add my $0.02 about my vision about reporting of test
>> results. I believe it's better to do this using HTTP rather than mail
>> because some people may not have access to SMTP port (for example, be
>> behind proxy with Exchange as mail server - I don't really know if it
>> provides SMTP service). HTTP is open in most  configurations and it
>> was already decided that HDK and tests will be delivered via HTTP.
>>
>> I see the reporting of the results in the following way: after
>> executing tests the script packs results and uploads them (as with
>> browser file upload) to the server. After that data is processed on
>> server-side - daemons can send periodical e-mails, draw charts,
>> reports, lists of top test results contributors, etc.
> 
> Nobody criticized this approach so I assume that it's not too bad. I'm
> going to implement a sketch for server-side bunch of scripts - one
> that accepts uploads and puts them to a temp directory and maybe some
> simple reports. They won't use any database. I believe that most
> common server-side engine is CGI (not PHP or J2EE) so I'd like to
> implement this using Perl CGI scripts. 

Have you thought of maybe... using...  Java?  I hear it's pretty good :)

>
> Since this is a first draft,
> I'm not going to use advanced templates language like XSLT. Including
> HTML output in script is bad idea so I'm going to use something like
> HTML::Template [1] for pages generation and CGI::Lite [2] for requests
> handling.
> 
> Perl is chosen just because it suites well for fast prototyping
> development.
> 
> If nobody objects, I'm going to start coding.

I do think we want to eat our own dogfood here and run it in Harmony.
Seriously.

Also, before you go off, can we chat about your proposed design a bit?

I'm still kinda stuck on email, as it means that everyone gets the messages.

One solution to that is pretty much what you suggested :

1) CI infra posts results to some apache-hosted website.  For now, I
think those results are simply "state change" (pass-> fail,  fail->pass)
with information about platform, and maybe relevant stack trace.  Given
that we want to keep some control over this, we could simply have an
"ID" issued by us when someone wants to participate, so they just submit
the ID + the info.

2) The website puts the results in a directory.

3) The website sends an email out reporting the transition and the
platform it happened on, w/ a link to the posted data from the reporting
server.

4) Summary pages are generated on the fly when someone looks...

So this is pretty much what you said, but I do agree w/ others that Perl
is wrong here.  There are great Java webapp frameworks (although I bet I
could do this in a day w/ a servlet...)

geir


> 
> [1] http://html-template.sourceforge.net/
> [2] http://search.cpan.org/~smylers/CGI-Lite-2.02/Lite.pm
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to