Re: TestFest 2010
| From: | till | Date: | Sun, 07 Mar 2010 16:39:14 +0000 |
| Subject: | Re: TestFest 2010 | ||
| References: | 1 2 | Groups: | php.qa |
| Request: | Send a blank email to php-qa+get-65511@lists.php.net to get a copy of this message | ||
On Tue, Mar 2, 2010 at 2:57 PM, zoe slattery
<zoe.slattery@googlemail.com> wrote:
> Hi Eric
>>
>> So I began to think of the real sore spots in writing and running PHP
>> tests
>> and here's what I came up with.
>>
>> 1. I plan to do a whole series of screencasts on writing and running PHP
>> tests. Cover running tests on Mac, Windows and Linux using fairly stock
>> configurations. Cover the different methods of running tests (single,
>> multiple, all).
>>
>
> Good idea.
>>
>> 2. Here's the biggy. I'd like to have a site where you can upload a test
>> and
>> have the test run against multiple versions of PHP and multiple OSes. How
>> do
>> we pull it off? Not a freakin clue. Maybe have a front-end site that
>> allows
>> the test upload which then pushes the test off to other servers and
>> aggregates the test results? Maybe store the test and results in a
>> database.
>> I don't know, but I'll continue to think on this and if anyone has any
>> ideas
>> and can offer coding time (and more importantly server resources), please
>> let me know.
>>
>
> I did this a bit last year. The _very hacky_ scripts that I used to do it
> are in SVN and I could probably find them. I don't recommend using them but
> they might serve a a checklist of things you need to think about. I only
> looked at two platforms, 32 bit and 64 bit Linux - this was worth doing and
> more platforms would be better, I had (have) no clue how to do Windows but I
> think Mac would be a reasonably easy addition. I'd also recommend doing the
> most simple possible thing - last year there was an hourly cron job on each
> platform that extracted tests and ran them against PHP52, 53 and 6. The next
> more complex thing would be to use a build system hooked into SVN that just
> builds (runs all the tests) after a pre-set number of SVN changes. This
> might be easy for someone who already knows how to do it, I ruled it out
> last year because I didn't have time to do it.
>
> It's worth thinking pretty hard about the file structure in the SVN repo - I
> think that was one thing we got about right and it made checking out tests
> and testing them reasonably easy.
We ("Berlin") used github last year, less hassle, fast, etc.. In the
end, we added all tests to the official repo.
As for the timeframe, I think if we did a 3 months thing everyone
would be able to get a date sorted. It takes effort to contribute and
while it would be nicer if everyone did all the time, the truth is,
they don't. ;) Having said that I think the momentum of an official
event is important and it's also easier to award prices if this is
between 2 dates vs. all year long.
Till