SitePoint Sponsor

User Tag List

Page 3 of 5 FirstFirst 12345 LastLast
Results 51 to 75 of 109
  1. #51
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    BTW the most common thing I face almost everyday is testing database-related activities,
    Not sure about what you are actually testing in the sense of what you need to do every day?

    a user signing up, a user modifying his/her options,
    This I think is a management task and nothing to do with actual development process, from what I can gather of your posting? Maybe you could explain some more...

    I'm still going through the stages of learning TDD myself, and still pushing myself to use SimpleTest more and more often. What I do is to create a class with the methods but leave them empty? ie

    PHP Code:
    interface IWalker {
    public function 
    __constructDOMElement $element );
    public function 
    walk();
    }

    class 
    XmlWalker implements IWalker {
    private 
    $name;
    private 
    $element;
    public function 
    __construct$element ) {
    // ...
    }

    public function 
    walk() {
    // ...
    }

    //...


    Then fill in the blanks during unit testing, though half the time I forge ahead ignoring unit testing as I don't have the time

    As for best practices I think unit testing is worthwhile once you've just gotten yourself into the habit of using it.

    McGruff,

    You don't have to use testing as a design tool.
    That's true, was only looking at it from it as I see it, there is certainly more to it

  2. #52
    SitePoint Zealot ceefour's Avatar
    Join Date
    Feb 2005
    Location
    Bandung, Indonesia
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    About "database testing":
    "This I think is a management task and nothing to do with actual development process, from what I can gather of your posting? Maybe you could explain some more..."

    No, it's not. What I meant was testing if the code/class/whatever for handling database-related activities are functioning properly, i.e., "bug-free". I'm not talking about test-driven development fully here (I'm still in very early learning here), just using Unit Testing as a tool for testing.

    For example when I've developed a class for user management. How do we test it? Well, open the sign up page, enter some data (invalid first, to check for validation code, then valid data). Then we check our local mail server, open the activation e-mail, then click it to see if the activation script works well. If all goes well, good, then we mingle around with user preferences or user features, whatever. If all goes well, we delete the user, hopefully in all those phases nothing goes wrong.

    See, what I described just above is a very real-world, very typical, practical example. Not just a class that handles only one test or a set of independent tests. The tests are very related, i.e. you can't test the "delete user" functionality if the user hasn't been created. And you can't activate a user before it's registered, etc.

    The other problem is consistency. Running this test suite should not leave the database in a dangling state, i.e. leaving the "test user" and not deleting it when any test fails. Running the test suite twice should produce the same result, however in case of inconsistent state this is unachievable because for the second running the "test user" didn't get deleted so it cannot create another test user.

    I hope to get some ideas.... really, practical, typical, and real-world examples and solutions. Getting used to the idea of unit test may not be that difficult... but designing the tests itself, I guess, is an art of its own. None of the freely available, downloadable, tutorials on unit tests (including lastcraft's, which is wonderful but it's for introduction purposes only) mentions this.

  3. #53
    SitePoint Zealot ceefour's Avatar
    Join Date
    Feb 2005
    Location
    Bandung, Indonesia
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So: SimpleTest or PHPUnit2?

    I think it's a pain in the (?) because I've to decide on... since I'll be committing to one. Even if just for learning. I guess it works basically the same but code is code. I just don't wanna regret in the long run because I picked a "wrong" library in the first time.

    It's like I've been using MDB 2... and when Creole/Propel came out I thought... "wow, why didn't I use that?" (well, Creole has only been here recently). Actually I can't switch since Creole doesn't have all the abilities of MDB that I need (especially the DDL (Data Definition Language) abstraction).

    So anyone (lastcraft?) would give me a nice enough review or comparison on this, even if just a bunch of list? At least, I want to know what lastcraft didn't like from PHPUnit[2]...... and if possible, what PHPUnit[2] can do that [currently] SimpleTest doesn't (and why? when it'll be implemented? etc.)

  4. #54
    SitePoint Zealot ceefour's Avatar
    Join Date
    Feb 2005
    Location
    Bandung, Indonesia
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hmm... It sure is not a "which one is better" question when comparing PHPUnit[2] with SimpleTest. After looking at some docs I think SimpleTest is more suited to me (or I'm more suited to SimpleTest) than PHPUnit[2].

    Somehow I hoped that SimpleTest would require PHP 5... It may be bad news to some people but for me it's very good news. Hmm... doesn't matter, as long as it works in PHP 5, a non-PHP5-only code is more than alright.

  5. #55
    SitePoint Zealot ceefour's Avatar
    Join Date
    Feb 2005
    Location
    Bandung, Indonesia
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Problem: When I opened simpletest1.0.tar.gz using WinRAR 3, it says CRC error? I downloaded from another mirror yet it still has this error. My file is 218.460 bytes.

    Tried extracting it and it seems to extract all files (correctly? I think so), but still with the CRC error.

    I used my Linux server to do a gunzip -t and it shows no error. tar -tz lists all files without problem, but since tar has no testing command I'm not sure about it.

    Weird. I've never had such problem before.

  6. #56
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    With regards to testing your database, and making sure it is in a consistant state, one option is to drop and re-create (and possibly repopulate with known data) the table in your setup() method. This method is called before each test method, so you can be assured each test is not interfering with the others.

    HTH

  7. #57
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    There's these two things called Mock Objects and Server Stubs which can be used excellently for database simulation. For example, you can test if a user management class is sending the right SQL queries to your database server by replacing the actual connection with a Mock object. So:
    The tests are very related, i.e. you can't test the "delete user" functionality if the user hasn't been created.
    You can test whether it sends out the correct queries to your database.

    Also, when you find that you can not test your classes without the use of a browser, it is very likely the sign that one class is doing too much by itself (i.e. a class that does both controller-related, presentation and database-related tasks) or that your classes are too tightly coupled: signs of bad design.

  8. #58
    SitePoint Zealot ceefour's Avatar
    Join Date
    Feb 2005
    Location
    Bandung, Indonesia
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the ideas. Seems great. However

    "Also, when you find that you can not test your classes without the use of a browser, it is very likely the sign that one class is doing too much by itself (i.e. a class that does both controller-related, presentation and database-related tasks) or that your classes are too tightly coupled: signs of bad design."

    It seems that we're usually testing classes or units. But how about testing functionality? To the user, "sign up" is just a functionality. But to us (the developers), this consists of several things... the sign up script (which may span several scripts), the sign up template(s), the user management class, and some other low level functionality (like database abstraction). It's clear that if a lower level unit doesn't pass a test than we can safely assume most of the higher level unit(s) won't pass some tests successfully.

    So how do we test functionalities as a whole? I.e. they that can span several scripts/units/files etc.? Just testing individual units (even if all of them passes) doesn't mean the functionality itself is bug-free.

  9. #59
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yeah, I've been thinking about that too. In the end I still end up 'fiddling' (i.e. clicking links, filling forms and trying some stuff)

    The proper solution is probably using something like SimpleTest's WebTester. But then you can't really test the contents of your database or use stubs/mocks.

  10. #60
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Ok, blow by blow here is how we do things at Wordtracker with the knotty problem you described. Yes it is real world and untangling stuff is not so easy and you will have to make some minor code changes. These will be for the better.

    When testing individual classes, we use mocks. I've gone off mocks for testing SQL unless it's very simple. Such tests are too constraining. I prefer an intergrated test for doing anything complicated. There is a sample test suite for a persistence layer here...

    http://www.sitepoint.com/forums/showthread.php?t=214183

    However you are not that well factored yet.

    The problem with acceptance/functional testing is in configuration. If things like the database name and mail port come from a configuration file, then you can switch that file during tests. This means that you can safely use a test database. I'll usually have something like this in the tests...
    PHP Code:
    class MyTest extends WebTestCase {
        function 
    setUp() {
            
    $this->switchToTestConfiguration();
            
    $this->clearDatabase();
        }

        function 
    tearDown() {
            
    $this->clearDatabase();
            
    $this->switchToLiveConfiguration();
        }

        ...

    ...because I can. It means I can inject just the test values I want.

    If this is not feasible then you have to dance the merry dance and be very careful inserting and removing data. You are also limited in what you can test, because real data will be mixed in.

    Regarding e-mail there are three approaches. In unit tests you want to mock the mailer, that's a no brainer. In functional tests you have two choices again.

    If you have control of your configuration you could change the port used to connect to your MTA from port 25 to something else. You cannot do this switch with the PHP mail() function, but you can do it with the phpmailer library. You then need a fake MTA. We have just open sourced a prototype (look for fakemail on Sourceforge at http://sourceforge.net/projects/fakemail/). You test case now has these parts...
    PHP Code:
    class MyMailTest extends WebTestCase {
        function 
    setUp() {
            
    $this->switchToTestConfiguration();
            
    $this->_pid = `fakemail --host=localhost --port=25025 --path=. --background`;
        }

        function 
    tearDown() {
            
    $command 'kill ' $this->_pid;
            `
    $command`;
            
    $this->switchToLiveConfiguration();
        }

        ...

    Any mails now sent are saved in the current directory. Note there are some socket issues we are working to resolve (hence the beta status).

    If you cannot do that then you will have to set up a POP mailbox with a test user and read from that. This is a real pain on development boxes, but it is possible.

    There is a book on working with legacy code, called unsurprisingly "working with Legacy Code" by Micheal Feathers.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  11. #61
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi.

    Regarding the comparison, PHPUnit follows JUnit and has fairly flexible internals. If you are developing a testing tool or are used to JUnit then that is a possibility. It also has test coverage, but I've never found that any real use.

    SimpleTest has mock objects and the web tester. As a 3.5 year PHP XPer it's based on my experience of the sort of issues faced day to day. Of course my issues may not be your issues...

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  12. #62
    SitePoint Addict
    Join Date
    May 2003
    Location
    Calgary, Alberta, Canada
    Posts
    275
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    It's now stable (version 1.0) and so I can start to look at creating new versions. This means I am again on the look out for new features and improvements. The more mad the better .
    Ok, a few mad feature requests:

    1) Dependent methods like testNG. If methodB depends on methodA and methodA fails methodB is Skipped.

    2) Groups like testNG. Individual methods can be apart of 1 or more groups.

    3) setUp* methods. Instead of only having a setUp() method run before each test run every method in the class that has a setUp prefix.

    4) tearDown* methods. Same as above.

  13. #63
    SitePoint Zealot ceefour's Avatar
    Join Date
    Feb 2005
    Location
    Bandung, Indonesia
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I've read the 2002 July draft of TDD By Example by Kent... Nice tutorial... but *sigh* still looks too simple in example to me, even the xUnit examples. I guess I needed more concrete examples... the real-world one, where you have classes communicating with (a dozen) other classes (duh! how coupled!) and also persistence... I guess not a tutorial, but a rather a "Test Patterns" by example (as opposed to "Design Patterns"). Not "unit" patterns like Fake It, Obvious Implementation, etc. but rather "if you're faced with a typical case like this, one object doing this another doing that and now you want to make a test for designing a functionality (or unit functionality)... this is what you should start with and bla bla bla" maybe like that.

    Anyways, I could foresee that one class would have a test class with at least 2-3 times the size of that own class with also multiple number of functions. Is this really the expected of TDD? I mean, you could easily have 6-10 or even more tests for even just one (simple) method, just to be on the safe side... Just imagining the sheer size of tests made me shutter (and yes, I haven't yet written any tests yet!)

    Some insights please...

  14. #64
    SitePoint Addict pachanga's Avatar
    Join Date
    Mar 2004
    Location
    Russia, Penza
    Posts
    265
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    PHP Code:
    class MyMailTest extends WebTestCase {
        function 
    setUp() {
            
    $this->switchToTestConfiguration();
            
    $this->_pid = `fakemail --host=localhost --port=25025 --path=. --background`;
        }

        function 
    tearDown() {
            
    $command 'kill ' $this->_pid;
            `
    $command`;
            
    $this->switchToLiveConfiguration();
        }

        ...

    How nice! Is it possible to have anything like that for windows?

  15. #65
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ceefour
    Anyways, I could foresee that one class would have a test class with at least 2-3 times the size of that own class with also multiple number of functions. Is this really the expected of TDD? I mean, you could easily have 6-10 or even more tests for even just one (simple) method, just to be on the safe side... Just imagining the sheer size of tests made me shutter (and yes, I haven't yet written any tests yet!)

    Some insights please...
    I don't know if there are any "expectations", but here is an example of a lines of code count from the latest project I am working on at work:

    Code:
    SLOC    Directory       SLOC-by-Language (Sorted)
    814     tests           php=814
    461     sql             sql=461
    228     models          php=228
    150     top_dir         php=150
    92      views           php=92
    75      actions         php=75
    0       CVS             (none)
    0       templates       (none)
    
    
    Totals grouped by language (dominant language first):
    php:           1359 (74.67%)
    sql:            461 (25.33%)
    So, out of the 1359 lines of code in this application, 814 of them are tests.

    Here is an example of testing a function in a model which calls an Oracle PL/SQL package function to retrieve a result set:

    PHP Code:
    class TestCdplan extends CdplanUnitTestCase 
    {
        function 
    TestPlantList() {
            
    $c = new MockADODB_oci8($this);
            
    $rs = new MockADORecordSet($this);
            
            
    $test_plants = array();
            foreach(
    $this->test_plants as $plant) {
                
    $test_plants[] = array('PLANT' => $plant);
            }
            
    $rs->setReturnValue('getArray'$test_plants);
            
    $rs->expectOnce('getArray');
            
    $c->setReturnValue('executeCursor'$rs);
            
    $expect = array(
                    new 
    WantedPatternExpectation('/'.preg_quote(CDPlan::PLANTS_FUNCT).'/')
                    ,
    BaseCdplanModel::cur_wrap()
                    ,array()
                    );
            
    $c->ExpectOnce('ExecuteCursor'$expect);
            
            
    $o $this->getCdp($c);
            
    $this->assertEqual($this->test_plants$o->getPlants(true));
            
            
    $rs->tally();
            
    $c->tally();
        }
        function 
    TestGetPlantsCache() {
            
    $c = new MockADODB_oci8($this);
            
    $c->ExpectNever('ExecuteCursor');
            
            
    $o $this->getCdp($c);
            
    $this->assertEqual($this->test_plants$o->getPlants(false));
            
            
    $c->tally();
        }
        
    // ...
    }

    class 
    TestCdplanIntegration extends CdplanUnitTestCase 
    {
        function 
    TestGetPlants() {
            
    $o $this->getCdp();

            
    $this->assertIsA($a $o->getPlants(true), 'array');
            
    $this->assertEqual(count($a), 4'4 Plants');
            
    //pick 3 random keys
            
    foreach (array_rand($a,3) as $key) {
                
    $this->assertTrue($key == (int)$key,"keys are all integers ($key)");
                
    $this->assertTrue(strlen($a[$key])==4,"values are 4 characters long ({$a[$key]})");
            }
        }
         
    // ...

    And here is an example of testing a typical "action":
    PHP Code:
    class TestSetFilterState extends CdplanActionUnitTestCase 
    {
        protected 
    $actionRequest 'filter';
        protected 
    $actionClass 'SetFilterState';
        function 
    __constructs($name='') {
            
    parent::__construct($name);
            
    Mock::Generate('Post');
        }
        function 
    setup() {
        }
        
    /**#@+
         *    test case
         *    @return    void
         */
        
    function TestEnv() {
            
    $this->assertTrue(class_exists($this->actionClass));
        }
        function 
    TestApplicationControllerDispatch() {
            
    $this->assertDispatch();
        }
        function 
    TestProcess() {
            
    $plant 'p'.rand(1,100);
            
    $rfp 'r'.rand(1,100);
            
    $mkt 'm'.rand(1,100);
            
            
    $post $this->getPost(array(
                 
    'plant'     => $plant
                
    ,'rfp'        => $rfp
                
    ,'mkt'        => $mkt
                
    ));
            
            
    $fs = new MockFilterState($this);
            
    $fs->expectArgumentsAt(0,'set',array('plant',$plant));
            
    $fs->expectArgumentsAt(1,'set',array('rfp',$rfp));
            
    $fs->expectArgumentsAt(2,'set',array('mkt',$mkt));
            
            
    $pico $this->getPico($post$fs);
            
    ApplicationController::processActions($pico);
            
    $this->assertRedirect('cdplan.php');
                    
            
    $post->tally();
            
    $fs->tally();

        }
        
    /**#@-*/    
        
        
        
    protected function getPico($post=false$fs=false) {
            
    $pico = new DefaultPicoContainer;
            
    ApplicationController::registerComponents($pico);
            if (
    $post instanceof iRequestHash) {
                
    $pico->unregisterComponent('Post');
                
    $pico->registerComponent(new InstanceComponentAdapter($post'Post'));
                
    $this->assertIdentical($post$pico->getComponentInstance('Post'));
            }
            if (
    $fs instanceof iFilterState) {
                
    $pico->unregisterComponent('FilterState');
                
    $pico->registerComponent(new InstanceComponentAdapter($fs'FilterState'));
                
    $this->assertIdentical($fs$pico->getComponentInstance('FilterState'));
            }
            return 
    $pico;
        }
        

    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  16. #66
    SitePoint Zealot ceefour's Avatar
    Join Date
    Feb 2005
    Location
    Bandung, Indonesia
    Posts
    138
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Mock objects..... Is it really the "design pattern" of TDD?

    I mean, by using mock objects you completely ignore the actual object altogether... even though the actual object may be very robust, how can you guarantee that the mock and the real object behaves the same way? You could be testing a database abstraction layer library by using mock objects as the abstracted database engine, but then... it will only be a "fake database abstraction layer library" since it's not even tested with the actual backend...??

    Dang... still confused. I guess TDD is more complicated than I had first imagined..... even the simple teeny weeny steps Kent explained in his book isn't enough to making it simple. :-( Or maybe I'm just plain idiotic.

  17. #67
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by pachanga
    How nice! Is it possible to have anything like that for windows?
    You could try running it through Cygwin or the ActiveState Perl distribution. I would be curious to seeif you get it working. Use the version in CVS as it gets updated constantly at the moment.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  18. #68
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by ceefour
    Some insights please...
    Try it!

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  19. #69
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Each mock or stub will be verified with its own tests.

    Also, once you have a bunch of passing tests, you can start testing groups of real classes working together.

  20. #70
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ceefour
    I mean, by using mock objects you completely ignore the actual object altogether... even though the actual object may be very robust, how can you guarantee that the mock and the real object behaves the same way? You could be testing a database abstraction layer library by using mock objects as the abstracted database engine, but then... it will only be a "fake database abstraction layer library" since it's not even tested with the actual backend...??
    I have Mocked the objects I am not testing. I want to test my code in isolation so I mock the objects which it colaborates with so that I am assured to have a knows set of inputs and responses during the test. I then have complete control over the envirnoment which I am testing my code.

    This allows me to simulate in the test environment conditions that would be hard to replicate in the real world, but which you do want your code to be able to handle. How do you create a failure of the database? Unplug the network cable? Stop the service? Anybody else using this at the same time is not going to be very happy with your testing.

    OTOH, with Mock objects, I can simulate the error message with would occour under that condition and verify my application code responds apporpriatly.

    Anyway, HTH.

  21. #71
    SitePoint Addict been's Avatar
    Join Date
    May 2002
    Location
    Gent, Belgium
    Posts
    284
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Try it!
    ceefour, there really isn't any alternative, you just have to try it to see what all the fuss is about.

    It took me about a weekend (around 20 hours if I remember correctly); I downloaded SimpleTest, went through the excellent online tutorial and then started writing tests for my own classes. I assure you, once you start seeing the green bar popping up, you do not want to go back.

    As for the "I don't have time to write tests"-excuse, well, don't even bother, I have found that my productivity has gone up (after it initially went down for a short while) since I started unit testing.

    Consider both the unit test and the unit being tested as 1 whole component, writing tests is about 50% of the job and writing the unit being tested also takes around 50%. When you look at it that way, it just isn't extra time is it, I mean you'll have to test at one point or the other, why not do it while you're developing instead of trying to cram it into the last week of a project's schedule (if you're lucky)
    Per
    Everything
    works on a PowerPoint slide

  22. #72
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by Brenden Vickery
    1) Dependent methods like testNG. If methodB depends on methodA and methodA fails methodB is Skipped.
    I am going to add an abandon() method which bails out of the entire test case. Would this be sufficient?

    Quote Originally Posted by Brenden Vickery
    2) Groups like testNG. Individual methods can be apart of 1 or more groups.
    Hmm...tricky. You can combine test cases into different group tests and I have an idea or two for making things easier on that score. I will delay this until better grouping is implemented because I don't think you'll need it then.

    Quote Originally Posted by Brenden Vickery
    3) setUp* methods. Instead of only having a setUp() method run before each test run every method in the class that has a setUp prefix.
    There is a problem in ordering the setUp()'s and actually it doesn't add much. After all you can explicitely call methods that don't start "test" in test methods anyway...
    PHP Code:
    function testStuff() {
        
    $this->setUpJustStuff();

        ...

        
    $this->tearDownJustStuff();

    This way you can even give them decent names.

    Quote Originally Posted by Brenden Vickery
    4) tearDown* methods. Same as above.
    Don't forget you can also create lot's of small test cases.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  23. #73
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I am going to add an abandon() method which bails out of the entire test case. Would this be sufficient?
    Indeed

    From the amount of times I've used unit testing, I'd say that it has helped increase the number of lines of script developed during that period of use on unit testing, over the times I don't use unit testing

    Why I don't use it day after day I don't know. I think I've yet to climitise to the idea of developing by the strict behaviour of unit testing. I like a little freedom just to fart about I suppose

  24. #74
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    I am going to add an abandon() method which bails out of the entire test case. Would this be sufficient?
    That would just abandon just the particular UnitTestCase, not group, right?

  25. #75
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by sweatje
    That would just abandon just the particular UnitTestCase, not group, right?
    That's right.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •