simpletest-support — Help, advice, bugs and workarounds.

[Simpletest-support] Alpha8 release

[Marcus B. <ma...@la...>]

Hi.

This release deprecates quite a few things that will later disappear 
come the Beta version. Mainly just name changes.

1) When including SimpleTest the following filenames have changed...
simple_html_test.php --> reporter.php
simple_mock.php --> mock_objects.php
simple_unit.php --> unit_tester.php
simple_web.php --> web_tester.php

2) The observer pattern is on the way out...
$test = &new MyTestCase();
$test->attachObserver(new TestHtmlDisplay());
$test->run();
...should be replaced with...
$test = &new MyTestCase();
$test->run(new HtmlReporter());

3) The basic HTML display class is now called HtmlReporter.

4) When setting options you now have to use the common class 
SimpleTestOptions...
GroupTest::ignore --> SimpleTestOptions::ignore()
Mock::setMockBaseClass() --> SimpleTestOptions::setMockBaseclass()

Sorry about all the hassle this will cause, but I figure it was better 
to get it over with. Both interfaces are supported in Alpha8 and this 
acts as an interim release until Beta1.

The rest of the release is just small improvements: Error trapping and 
testing, page redirects and extra mock object expectations.

yours, Marcus.
-- 
Marcus Baker, ma...@la..., no...@ap...

[Simpletest-support] Re: simple test advice

[Marcus B. <ma...@la...>]

Hi...

McKenna, Simon (RGH) wrote:
> Your advice has confirmed my suspicions, so I'll only
> write tests for new code (and will start small), the
> existing code will have to wait until the PHP 5 port.
> 
> Thanks again!  Will let you know how I go.

Cheers. That would be great.

> 
> Regards,
> Simon McKenna
> 

yours, Marcus
-- 
Marcus Baker, ma...@la..., no...@ap...

[Simpletest-support] Re: How can you test this using simple test?

[Marcus B. <ma...@la...>]

Hi...

I think if you post this on one of the PHP forums as well you will get a
healthy response. Anyway, here goes....

info wrote:
> The relationship is quite simple. The application is the main program 
> and it has a user object. Each time the application runs, it will check 
> if the current user has the right to do the current action(by the 
> onload() function). The current user has a list of actions that he has 
> the right to do, so the user will check the current action against his 
> own action list.The user's own action list is generated when the user is 
> initialized and through the UserDao object ().
> Since the UserDao is very closed to the database, so I want to code it 
> later, but want to write a test case for class User and test the 
> checkPerms() function now.

Ok, I'll tackle the getParms() method.

>  
> I know there are mock and server stub in the simple test, and read the 
> logingsessionpool  sample dozens of times but have totally no idea how 
> to use them in my test case.

Which does kind of imply I screwed up the explanation at that point. I
had better rethink that part.

There is a deeper, but slightly out of date, tutorial at
http://www.lastcraft.com/first_test_tutorial.php although it is a bit
too long really.

>  
> Can you give me more hint or sample on the case?

Ok, it's a big question! I'll start by assuming that you have got as far
as getting a simple test case to run (see the tutorial on the LastCraft
site if you are stuck). If you haven't then we'll have to backtrack.

You have two complications. The first is very common, that of getting a
mock into a class that creates objects within itself. The other is that
things have got a little coupled making it difficult to isolate objects
for testing. Both are easy to deal with though.

We need slight modifications to the user to get a mock in there...

function User(&$app, &$session, $dao = false) {
    if (!isset($session['user'])) {
        $session['user']['uid']=0;
        $session['user']['name']='Guest';
        $session['user']['errors']='';
    }
    $this->uid = $session['user']['uid'];
    if (!$dao) {
        $dao = &new UserDao($app->getDatabase());
    }
    $this->userDao = &$dao;
    $this->actionList = $this->userDao->getUserActions($this->uid);
}

I have also removed the global $_SESSION so that we can replace it
during testing. Otherwise tests will interfere with each other. This
forces you to pass the session data around, but this is probably better
practice anyway. The test cases are now a lot easier...

// tests/user_test.php
//
require_once("application.php");
require_once("user.php");
require_once("user_dao.php");
Mock::generate("Application");
Mock::generate("UserDao");

class UserTest extends UnitTestCase {
    function UserTest() {
        $this->UnitTestCase();
    }
    function testSessionPlacementIfNew() {
        $app = &new MockApplication($this);
        $dao = &new MockUserDao($this);
        $session = array();
        new User($app, $session, &$dao);
        $this->assertEqual(
                $session,
                array('user' => array(
                        'uid' => 0,
                        'name' => 'Guest',
                        'errors' => '')));
    }
    function testPermissions() {
        $app = &new MockApplication($this);
        $dao = &new MockUserDao($this);
        $dao->setReturnValue('getUserActions', array('Ok'));
        $session = array();
        $user = &new User($app, $session, &$dao);
        $this->assertFalse($user->checkPerms('No way'));
        $this->assertTrue($user->checkPerms('Ok'));
    }
}

Of course you will still have to do a later integration test to make
sure all of the pieces do all really work together, but that kind of
test is simpler by then.

You will still have a few problems later though. If the only connection
of the Application to the User is to supply the database connection then
it is probably better to pass the connection in rather than the whole
application with $this. Also you could move all of the data object
creation into just one class called DataLayer or PersistenceBroker. That
way you would only have to mock one object less things would be tied to
the Application class. Just a suggestion though.

Good luck!

>
> Thank you very much
> Ji Tao

I only hope this actually helps. :)

yours, Marcus

Here is your original code btw (compressed down a bit)...

class Application {
  var $usr;
  var $database;

  function Application() {
   $this->usr = &new User($this);
   $this->database = &new Database('mysql','localhost','root','password');
  }
  function &getDatabase() {
   return $this->$database;
  }
  function onLoad() {
   if ($this->usr->getUid()) {
    $action = $this->getCurrentAction();
    if (!$this->usr->checkPerms($action)) {
     //redirect the user to no permission page.
    }
   } else {
    //redirect to login page
   }
  }
  function getCurrentAction() { ... }
 }

 class User {
  var $uid;
  var $name;
  var $login;
  var $email;
  var $userDao;
  var $actionList = array();

  function User (&$app) {
   if(!isset($_SESSION['user']))
   {
    $_SESSION['user']['uid']=0;
    $_SESSION['user']['name']='Guest';
    $_SESSION['user']['errors']='';
   }
   $this->uid = $_SESSION['user']['uid'];
   $this->userDao=new UserDao($app->getDatabase());
   $this->actionList=$this->userDao->getUserActions($this->uid);
  }

  function getUid () {
   return $this->uid;
  }

  function checkPerms($action) {
   if(in_array($action, $this->actionList)) {
    return true;
   }
   return false;
  }
 }

 class UserDao {
  function getUserName() { ... }
  function getUserActions($uid) { ... }
  function getUserEmail($uid) { ... }
  function changePassword() { ... }
  function login($login,$password) { ... }
 }

-- 
Marcus Baker, ma...@la..., no...@ap...

[Simpletest-support] Re: simple test advice

[Marcus B. <ma...@la...>]

Hi...

McKenna, Simon (RGH) wrote:
> In your experience (I'm a unit test neophyte) is it advisable to retrofit
> existing classes with unit test classes?  

This is a common problem and a difficult situation. The short answer is 
no. Testing as you go slows development slightly even when you start out 
with all the other components tested and you are skilled at test first. 
Of course you more than make up the time later, but you will take a 
tremendous hit if you go back and write tests for all the preceding 
classes. And it's pretty boring.

The usual advice is to test only your new stuff plus anything it comes 
into contact with. This is a double hit, but tolerable. Unfortunately 
you will be taking another short term hit because you are new to the 
tools as well. My feeling is to find a pretty isolated bit of code and 
write that test first. Once you have spent a couple of days feeling your 
way you will start to reap the benefits. Once you get that positive 
feedback then you will feel happier about the double hit of slowly 
adding tests on a need basis.

> 
> It appears preferable to write tests as you are developing classes, but for
> a particular open source project I've been working on for a while
> (flashPash.sshnug.com),  I've come to the conclusion that as it has grown in
> complexity and scope, a robust test framework is needed.

You will need tests so as to safely make changes later. By way of 
encouragement the "test infection" will kick in shortly and you will 
actually start to like writing tests because of the freedom it gives 
whilst coding. You can try things, watch the screen go red and then back 
out safely. Now even the big projects are fun.

> 
> So now I have decision to make...I started writing my own test scripts, but
> now realise this isn't the best solution, and should use an existing
> framework (i.e.. simple_test / pear::phpunit) so do I wait for my PHP 5
> rewrite of flashPash and develop the new classes in tandem with test
> classes, or will it be worth my while to create test classes for the
> existing classes?

As I said I would refactor the old tests on a need basis or you will 
slow the development of features too much. If it's any consolation I 
have the same problem with large a codebase as well. About 10000 lines 
of test code, 3000 tests in about 80 test scripts! My workaround at the 
moment is to treat the old test scripts as a web page to be tested so 
that I can integrate them with the cases so far ported to SimpleTest. 
Something like...

class OldTests extends WebTestCase {
     function OldTests() {
         $this->WebTestCase();
     }
     function testOldScripts() {
         $this->get('http://localhost/projects/tests/old_tests.php');
         $this->assertNoUnwantedPattern('/fail/i');
     }
}

At least that way all the tests run together and I can refactor gradually.

> 
> I'm unsure, so if you could give any guidance, it would certainly be
> appreciated.

Really just start with a small section of code. The rewards will come 
quickly (trust me please). Also you will be amazed just how many bugs 
will show up in that old code :).

> 
> Thanks for your time and thoughts.
> 
> Regards, 
> Simon McKenna 
> Senior Analyst / Programmer
> Information Services - extension 1409
> Repatriation General Hospital - 8276 9666
> 

No problem. Let us know how you get on.

yours, Marcus
-- 
Marcus Baker, ma...@la..., no...@ap...

Re: [Simpletest-support] Re: require help

[Marcus B. <ma...@la...>]

Hi...

dollar k wrote:
> hi baker,

It's Marcus.

>           thanks for your previous response.
> we have developed a email validation function, where should i plug my 
> code in your simple test package to test my email validation.

Firstly I have to format your code...

function email($var, $type, $args=0) {
     $length = strlen($var);
     $idx = 0;
     while ($length--) {
         $c = $var[$idx++];
         if (ord($c) > 127){
             return false;
         }
     }
     $regexp = 
'/^(?:[^\s\000-\037\177\(\)<>@,;:\\"\[\]]\.?)+@(?:[^\s\000-\037\177\(\)<>@,;:\\\"\[\]]\.?)+\.[a-z]{2,6}$/Ui';
     if (preg_match($regexp, $var)) {
         return true;
     } else {
         return false;
     }
}

Please send questions in plain text in future, rather than HTML.

 From the code I see that you are verifying an email address. Here is a 
possible test case...

class TestOfValidEmails extends UnitTestCase {
     function TestOfValidEmails() {
         $this->UnitTestCase();
     }
     function testNastyCharacter() {
         $this->assertFalse(email("me\12...@ma...", "?", "?"));
     }
     function testNoName()
         $this->assertFalse(email("mail.somewhere.com", "?", "?"));
     }
     function testValidAddress() {
         $this->assertTrue(email("me...@ma...", "?", "?"));
     }
}

You will probably think of other tests you can add as well. I have 
marked some parameters with "?" simply because I don't know what they 
are for.

See the tutorials at http://www.lastcraft.com/first_test_tutorial.php 
for how to run this test case.

>  
> Waiting for a quick response from you sir.

I'll take as long as I want.

> regards,
> padmaja

yours, Marcus
-- 
Marcus Baker, ma...@la..., no...@ap...

[Simpletest-support] Re: require help

[Marcus B. <ma...@la...>]

Hi...

dollar k wrote:
> 
> Hi Baker,
>      good morning,
>   thank you very much for your reply.
> i am ok in programming ut not an advanced programmer.
> from past 2days i have been working on httpunit, i could fairly install 
> it, i have to start my work on it.

Good. That will fill any gaps that currently exist in SimpleTest. You 
may also find that HtmlUnit or JWebUnit are easier to use. JWebUnit is 
the insipration for the SimpleTest interface as is.

> regarding simple test i can send you as anattachment our registration 
> form can u plz tell me how i should proceed in the simple so that basing 
> this i can apply to other functionlites.
> if it possible for you to kindly write the function i will send you 
> tomorrow the code.
>  
> waiting for your reply
> thanks
> regards
> padmaja
> 

I'll have a go, but please post it to 
sim...@li... so that others may reply too, 
or better yet post it on the sitepoint forums. You will get a lot of 
response there. Can you also send your mails so far to the mailig list 
so that I have  acomplete recxord there.

yours, Marcus.
-- 
Marcus Baker, ma...@la..., no...@ap...

[Simpletest-support] Re: require help

[Marcus B. <ma...@la...>]

Hi.

dollar k wrote:

Can you send your request to the simpletest support forum as well as 
this address.

> I am very new to php,

Have you done any object oriented work before? If not, then this is 
going to be a struggle.

 > can
> u kindly send me any sample application for the registration form where 
> i can replace by my functions and i can do the test.
> i am sorry if i am troubling you.

Form handling is still being written. In fact it is part of this 
development cycle, so you have asked exactly one month too early :(. You 
can bundle request data into a page fetch like so...

class RegistrationTest extends WebTestCase {
     function RegistrationTest() {
         $this->WebTestCase();
     }
     function testFailedLogin() {
         $this->post(
                 'http://www.site.com/register.php',
                 array('name' => 'fred', 'password' => 'wrong', 'submit' 
=> 'Go'));
         $this->assertWantedPattern('/not allowed/i');
     }
}

There are better ways of doing this in the pipe right now. If you can 
wait a month until SimpleTest enters Beta then things should be easier 
and I will have some tutorials up by then. In the meantime I will only 
be able to help you if you are a reasonably advanced programmer. Have 
you built stuff in Java or are you new to software development in 
general? Have you used JUnit or HttpUnit in Java?

> thanks once again
> regards
> padmaja

Don't forget to post your old message to the support forum.

yours, Marcus
-- 
Marcus Baker, ma...@la..., no...@ap...

[Simpletest-support] Re: how to start?

[Marcus B. <ma...@la...>]

Hi...

dollar k wrote:
> *Warning*: main(path_to_simple_test/simple_unit.php): failed to open 
> stream: No such file or directory in 
> *C:\Inetpub\wwwroot\simpletest\all_tests.php* on line *5*

The "path_to_simple_test" bit you were supposed to replace with the 
place where you have installed the simpletest files. I would put the 
all_tests.php, etc in a folder within your project or alongside it. So 
if your project is in a folder c:/home/me/project then place them in 
c:/home/me/project/test or c:/home/me/test perhaps. Otherwise you will 
clutter the simpletest folder with lots of project specific stuff.

When you set the SIMPLE_TEST constant you set it to the location of the 
simpletest files, so in your case...

define('SIMPLE_TEST', 'C:/Inetpub/wwwroot/simpletest/');

You may have to swap the forward slashes for escaped backslashes, but I 
doubt it. That should work.

yours, Marcus
-- 
Marcus Baker, ma...@la..., no...@ap...

Re: [Simpletest-support] test failure in alpha7 package

[Marcus B. <ma...@la...>]

Hi.

Jason Sweat wrote:
> A comparison to http://www.time.gov/timezone.cgi?Central/d/-6 showed me off by
> about 50 seconds.  After correction, all tests passed!

Cool. I have opened the bug until I have changed the cookie timings to 2 
days in the test suite and added a clock drift check with a more 
informative message.

Thanks for the info.

yours, Marcus.
-- 
Marcus Baker, ma...@la..., no...@ap...

[Simpletest-support] Re: how to start?

[Marcus B. <ma...@la...>]

Hi.

First of all you mail address is blocked by the spam filtering. Do you 
have a more natural mail address as it is likely I will miss your postings?

Regarding the start up process the best bet is to at the tutorial at 
http://www.lastcraft.com/first_test_tutorial.php as a gentle lead in 
(I'll be tidying it all up soon). The short answer though is to create 
two files.

all_tests.php...

<?php
     if (!defined('SIMPLE_TEST')) {
         define('SIMPLE_TEST', 'path_to_simple_test/');
     }
     require_once(SIMPLE_TEST . 'simple_unit.php');
     require_once(SIMPLE_TEST . 'simple_html_test.php');

     $test = &new GroupTest('All tests');
     $test->addTestFile('my_test.php');
     $test->attachObserver(new TestHtmlDisplay());
     $test->run();
?>

my_test.php...

<?php
     class MyTest extends UnitTestCase {
         function MyTest() {
             $this->UnitTestCase();
         }
     }
?>

If you point the browser at the all_tests.php it should inform you that 
zero test cases passed with zero failures. If it doesn't then post your 
scripts and we'll take it from there.

You can now add tests to the new test case. These are just functions 
that start with the name "test". You can also add more test case classes 
to the file or add more files to all_tests.php file later on.

yours, Marcus.
-- 
Marcus Baker, ma...@la..., no...@ap...

[Simpletest-support] how to start?

[dollar k <dol...@ya...>]

Hi all,
I have looked at the Simple Test, that looks fabulous.
How do i start, working with  that,
i have the whole directory in my localhost dir, & i can access using apache.
Plz telll me which is the starting file to see how it works?
thanks
Padmaja


---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

Re: [Simpletest-support] test failure in alpha7 package

[Jason S. <jsw...@ya...>]

My ping time to www.lastcraft.com does not look too bad:

$ ping www.lastcraft.com
PING www.lastcraft.com (80.249.111.100) from 192.168.10.35 : 56(84) bytes of
data.
64 bytes from 80.249.111.100: icmp_seq=0 ttl=238 time=134.729 msec
64 bytes from 80.249.111.100: icmp_seq=1 ttl=238 time=109.510 msec
64 bytes from 80.249.111.100: icmp_seq=2 ttl=238 time=108.734 msec
64 bytes from 80.249.111.100: icmp_seq=3 ttl=238 time=109.956 msec
64 bytes from 80.249.111.100: icmp_seq=4 ttl=238 time=110.019 msec
64 bytes from 80.249.111.100: icmp_seq=5 ttl=238 time=108.591 msec

The change to time() + 115 did not alter the check,

and my box is set to "random drift time" :) 

A comparison to http://www.time.gov/timezone.cgi?Central/d/-6 showed me off by
about 50 seconds.  After correction, all tests passed!

Jason


--- Marcus Baker <ma...@la...> wrote:
> Hi...
> 
> Jason Sweat wrote:
> > Hi Marcus,
> > 
> > I downloaded the php_simple_test_1.0alpha7 tarball from sf.net, unpacked it
> and
> > ran the tests/all_tests.php script.
> > 
> > All tests
> > Fail: Boundary
> > tests->live_test.php->testoflivecookies->testtimedcookieexpiry->Not
> expecting
> > cookie [short_cookie]
> > 51/51 test cases complete: 961 passes and 1 fails.
> > 
> > The unit_tests script runs fine.
> > 
> > I saw the archive email from 8-15 for this list stating: Please use only
> the
> > unit_tests.php script until Alpha7. But I thought I would report it since I
> am
> > using Alpha7 :)
> 
> That's correct. I had to update the sample test pages whilst I was 
> rolling out Alpha7, thus invalidating Alpha6's tests.
> 
> The test is actually quite straightforward...
> 
> function testTimedCookieExpiry() {
>      $this->get('http://www.lastcraft.com/test/set_cookies.php');
>      $this->restartSession(time() + 101);
>      $this->assertNoCookie("session_cookie");
>      $this->assertNoCookie("short_cookie");
>      $this->assertCookie("day_cookie", "C");
> }
> 
> It reads the cookies from the test page and then jumps 101 seconds into 
> the future (closing and reopening the browser) to see which have 
> expired. The test page starts with...
> 
> <?php
>      setcookie("session_cookie", "A");
>      setcookie("short_cookie", "B", time() + 100, "/");
>      setcookie("day_cookie", "C", time() + 24 * 3600, "/");
>      setcookie("path_cookie", "D", time() + 100, "/test/path/");
> ?>
> 
> Of course I have allowed a one second margin of difference between the 
> server and client+transport times! Being close to the server (30ms ping) 
> on all the machines I tested with sunk me on this one.
> 
> Ok first of all I need to allow 15 seconds at least for the wire time. 
> If you just hack the test to...
> 
> $this->restartSession(time() + 115);
> 
> ...that should fix it. Is your client box using an internet clock signal 
> (such as NTP or NITS)? I hope the lastcraft server is or I am in big 
> trouble. If you are not and it still fails then the test suite is 
> probably correctly reporting a failure in the test environment. Of 
> course it's not the job of the tester tests to report this, but...
> 
> How about this for a plan?
> 
> I'll up the short cookie plus margin to two days rather than 101 secs 
> (in case people have forgotten to set the TZ variable) and the day 
> cookie will become a month cookie. I'll add a seperate tighter test with 
> an explicit description of the timing issues with a fifteen second wire 
> time to replace the above. I won't be able to change the tests until 
> just before Beta1.
> 
> This should normally work and drop a meaningful hint about clocks and 
> cookies and testing if people haven't set up their machines with this in 
> mind.
> 
> Meanwhile I'll confirm that the time is correct at lastcraft.
> 
> > 
> > Regards,
> > 
> > Jason
> > 
> > P.S. the readme lists this list's email address as 
> > sim...@so... when it is actually 
> sim...@li...
> > 
> 
> Ouch. That probably means that we are the only members :(. I'll fix that 
> straight away in CVS and enter the above as bug reports.
> 
> yours, Marcus
> -- 
> Marcus Baker, ma...@la..., no...@ap...
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: [Simpletest-support] test failure in alpha7 package

[Marcus B. <ma...@la...>]

Hi...

Jason Sweat wrote:
> Hi Marcus,
> 
> I downloaded the php_simple_test_1.0alpha7 tarball from sf.net, unpacked it and
> ran the tests/all_tests.php script.
> 
> All tests
> Fail: Boundary
> tests->live_test.php->testoflivecookies->testtimedcookieexpiry->Not expecting
> cookie [short_cookie]
> 51/51 test cases complete: 961 passes and 1 fails.
> 
> The unit_tests script runs fine.
> 
> I saw the archive email from 8-15 for this list stating: Please use only the
> unit_tests.php script until Alpha7. But I thought I would report it since I am
> using Alpha7 :)

That's correct. I had to update the sample test pages whilst I was 
rolling out Alpha7, thus invalidating Alpha6's tests.

The test is actually quite straightforward...

function testTimedCookieExpiry() {
     $this->get('http://www.lastcraft.com/test/set_cookies.php');
     $this->restartSession(time() + 101);
     $this->assertNoCookie("session_cookie");
     $this->assertNoCookie("short_cookie");
     $this->assertCookie("day_cookie", "C");
}

It reads the cookies from the test page and then jumps 101 seconds into 
the future (closing and reopening the browser) to see which have 
expired. The test page starts with...

<?php
     setcookie("session_cookie", "A");
     setcookie("short_cookie", "B", time() + 100, "/");
     setcookie("day_cookie", "C", time() + 24 * 3600, "/");
     setcookie("path_cookie", "D", time() + 100, "/test/path/");
?>

Of course I have allowed a one second margin of difference between the 
server and client+transport times! Being close to the server (30ms ping) 
on all the machines I tested with sunk me on this one.

Ok first of all I need to allow 15 seconds at least for the wire time. 
If you just hack the test to...

$this->restartSession(time() + 115);

...that should fix it. Is your client box using an internet clock signal 
(such as NTP or NITS)? I hope the lastcraft server is or I am in big 
trouble. If you are not and it still fails then the test suite is 
probably correctly reporting a failure in the test environment. Of 
course it's not the job of the tester tests to report this, but...

How about this for a plan?

I'll up the short cookie plus margin to two days rather than 101 secs 
(in case people have forgotten to set the TZ variable) and the day 
cookie will become a month cookie. I'll add a seperate tighter test with 
an explicit description of the timing issues with a fifteen second wire 
time to replace the above. I won't be able to change the tests until 
just before Beta1.

This should normally work and drop a meaningful hint about clocks and 
cookies and testing if people haven't set up their machines with this in 
mind.

Meanwhile I'll confirm that the time is correct at lastcraft.

> 
> Regards,
> 
> Jason
> 
> P.S. the readme lists this list's email address as 
> sim...@so... when it is actually  sim...@li...
> 

Ouch. That probably means that we are the only members :(. I'll fix that 
straight away in CVS and enter the above as bug reports.

yours, Marcus
-- 
Marcus Baker, ma...@la..., no...@ap...

[Simpletest-support] test failure in alpha7 package

[Jason S. <jsw...@ya...>]

Hi Marcus,

I downloaded the php_simple_test_1.0alpha7 tarball from sf.net, unpacked it and
ran the tests/all_tests.php script.

All tests
Fail: Boundary
tests->live_test.php->testoflivecookies->testtimedcookieexpiry->Not expecting
cookie [short_cookie]
51/51 test cases complete: 961 passes and 1 fails.

The unit_tests script runs fine.

I saw the archive email from 8-15 for this list stating: Please use only the
unit_tests.php script until Alpha7. But I thought I would report it since I am
using Alpha7 :)

Regards,

Jason

P.S. the readme lists this list's email address as 
sim...@so... when it is actually  sim...@li...

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

[Simpletest-support] Alpha 7 release

[Marcus B. <ma...@wo...>]

Hi.

I have just released alpha 7 and am planning the next (Beta) release.

The TODO list for the month currently includes...
1) Form submission in the web tester.
2) HTML parsing improvements including CSS and Javascript skipping.
3) Following of redirects in the web tester.
4) Swapping the observer patern for a visitor pattern internally to 
improve the ease of writing GUI interfaces.

If anyone wants any other feature, or just better 
documentation/tutorials, please drop me a line.

yours, Marcus.
-- 
Marcus Baker, Head of Technical, Wordtracker.
ma...@wo...
ma...@la...

[Simpletest-support] Upcoming change of interface

[Marcus B. <ma...@la...>]

Hi.

The fetch() method in the WebTestCase class is about to change it's name 
to get(). This is so I can also have a post() method of course and I now 
have to go away and repeatedly kick myself in the head for being so 
stupid. :(

I'll maintain fetch() as a psuedonym for a release or two.

yours, Marcus.
-- 
Marcus Baker, ma...@la..., no...@ap...

[Simpletest-support] Changes to test pages

[Marcus B. <ma...@la...>]

Hi.

The test pages on the lastcraft site have had a major rework. I am 
afraid that this means that if the all_tests.php script is run some 
failures will be reported. Please use only the unit_tests.php script 
until Alpha7.

I cannot imagine this has caused anyone any inconvenience. I thought I 
had better mention it just in case.

yours, Marcus
-- 
Marcus Baker, ma...@la..., no...@ap...

[Simpletest-support] FAQ

[Marcus B. <ma...@la...>]

Hi.

I would like to start a PHP unit testing FAQ on my web site (not 
restricted to SimpleTest). If anyone has questions that they want 
answered or have answers that they think might be helpful, please post 
them here.

yours, Marcus
-- 
Marcus Baker, ma...@la..., no...@ap...