SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 41 of 41
  1. #26
    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 Dr Livingston
    Oh!! I just put it at the top of each page, isn't it a requirement (best practice) now?

    PHP Code:
    error_reportingE_ALL E_STRICT ); // is what I use 
    E_STRICT (a.k.a. E_ANAL ) basically just highlights where you are still using PHP4 idioms which have been replaced by new PHP5 contstructs (passing objects by reference, lack of function visibility declaratoin, etc.)

    Certainly not a requirement (seeing how hard it is to actually get E_STRICT actually enforced) but a good idea if you want to code for a strictly PHP5 code based and want to be reminded where you are using older coding habits.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  2. #27
    SitePoint Enthusiast
    Join Date
    May 2004
    Location
    K.S.A
    Posts
    81
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    E_STRICT (a.k.a. E_ANAL ) basically just highlights where you are still using PHP4 idioms which have been replaced by new PHP5 contstructs (passing objects by reference, lack of function visibility declaratoin, etc.)
    it's not like E_ANAL! :P
    recalling what I read about E_ANAL, it was about PHP being strictly typed and enforcing more OO aspects

    http://www.akbkhome.com/blog.php/Vie...g+setting.html

  3. #28
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    How about E_TDD:

    Unexpected PHP error [Cannot find unit test for class] severity [E_USER_ERROR]

  4. #29
    SitePoint Enthusiast
    Join Date
    May 2004
    Location
    K.S.A
    Posts
    81
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I could safely say this is an E_ANAL error

  5. #30
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    if you want to code for a strictly PHP5 code based and want to be reminded where you are using older coding habits.
    Well, exactly as this is the reason I use E_STRICT. I have no intentions of reverting back to PHP4.x.

    What a disgusting thought

  6. #31
    SitePoint Enthusiast ssx-gun's Avatar
    Join Date
    Sep 2002
    Location
    Strongsville, OH
    Posts
    97
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    "Until it works" is far too vague. Tests for a single app might make thousands - even tens of thousands - of precise assertions. There's no way you can reliably verify these by hand.
    Lets not forget its only PHP , but I would like to note that during this process I may not have said it but people are going to most likely make small outputs to make sure an app will be working at a certain point. If they see the break they may look for what holds it up from there. Most people would not be completely ignorant as to just write hundred to thousands of lines of code per page without slight testing or a check mechanism for all that code if they dont want to stop.

    A simple echo can work wonders.
    PHP: Pills Help People
    ---
    weird-one.com


  7. #32
    SitePoint Addict timvw's Avatar
    Join Date
    Jan 2005
    Location
    Belgium
    Posts
    354
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I also started with simple echoing things.. And a bit later i started to like tools like gdb (xdebug and friends for php) too... But after a will you notice that you are doing the same things over and over again... And every time you change something in the code you fall back into the routing of adding/removing echo statements to make sure everythings works as expected.

    Imho the advantage of TDD is that you write the tests once... And can reuse them anytime you want afterwards.

  8. #33
    SitePoint Addict pachanga's Avatar
    Join Date
    Mar 2004
    Location
    Russia, Penza
    Posts
    265
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    [offtopic]

    Quote Originally Posted by lastcraft
    Hi...
    I once saw a bad translation of a Russian phrase which captures this quite well: "train your fantasy". I don't know how to "train your fantasy", but I guess you have to think whimsically about all possible disasters.
    Marcus, do you have any links to the original Russian phrase? I really can't figure out the equivalent

  9. #34
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ssx-gun
    Lets not forget its only PHP
    That's exactly why I try to push testing so hard. Php is a jungle of bad code. I know, I've written my share. If I'm trying to judge a program the first question I always ask myself is: are they testing?

  10. #35
    ********* 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
    Marcus, do you have any links to the original Russian phrase? I really can't figure out the equivalent
    Nyet .

    It was from "Think Like a Grandmaster" by Alexander Kotov. My Russian is not up to the original, so I garnered it from the English translation.

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

  11. #36
    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
    Nyet

  12. #37
    SitePoint Enthusiast silicate's Avatar
    Join Date
    Nov 2004
    Location
    Toronto
    Posts
    43
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Testing - more art than science

    Hey there,

    So I am starting to use simpletest to test my code (for the third time). I was having a lot of trouble breaking the habit of just ploughing through the new code thinking that it would be faster just to write the code. I mean, it's only a simple helper class to sort a list after all...

    Recently though, I have had a sort of mini-revelation and have decided to step up my development habits. I started using CVS, I have tools for deploying new web sites frameworks, and now I am starting to Unit Test before I get into continous integration stuff. So far I am happy with it all, it really feels like I am in control of my libraries.

    Instead of always "forgetting" to update one (or more) version of my database class, a there is one class file that is in a central location out of the doc root. Any changes I make that mess things up can quickly be reverted with CVS and I can examine the problem more carefully before checking in the code and then updating the common source tree.

    Unit testing seems to be really helping me in several aspects. First, I think about what I am going to be getting back from each method before I actually write it. Second, I haven't had to do a print_r() in my latest project once. That alone is worth it, try debugging a script that dumps your echo/print_r to a hidden div. Then you encapsulate your print_r in an echo to make sure that the print_r is actually working somewhere. But then you gotta view source anyway... And then it turns out that the variable you print_r()'d wasn't where the bug was and that was all a waste of time. Finally, I can see that in the future, I am going to be able to update things without having to worry too much about a bug that will pop up that a User won't notice and you end up with 50,000 corrupted database records that you pray you can write a script to fix rather than having to use phpMyAdmin.

    One thing that I was wondering - and this relates to the subject of this post - is it is possible to have a test depend on another one passing? It's kinda annoying (and distracting) to get a whole set of errors because a method that is used by other methods fails.

    A clean error like this would be nice:
    Fail: tests/DAOTest.php -> testofdao -> testgetSomeObjects -> Test Depends on Failed Test tests/DAOTest.php -> testofdao -> testgetObject

    Rather than having all of the asserts inside of testgetSomeObjects fail. Or I am not writing my tests properly?

    Umm, this post got long, but I don't post often so I hope I am forgiven

    Be safe,

    Matthew.

  13. #38
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    With a long list of failures, there might be one small problem producing a knock-on effect or there might be many problems to iron out. If you've been following the testing mantra closely - write a little test, write a little code to pass the test - it'll probably just be one thing.

    The emphasis is on little steps so that problems are caught early while they're easy to fix. Even so, you can sometimes have a long list of failures to wade through, as you say.

    If you are running a group of tests a problem in one class could also be causing problems elewhere. If you switch to a single file-runner that lets you focus on the class being edited - but don't focus too tightly. You might want to keep running the group tests every now and then as you work since the class being edited has to integrate properly with everything else as well as passing its own tests. Little steps and test allows you to contain errors before they disappear over the horizon.

    Or, maybe you're getting a long list of failures in a single test case. If you can identify a test method which directly addresses the last piece of code you've edited, deal with that first and maybe the other failures will just magically vanish. Or not...

    The way you write tests is important. I think you do need to consciously create tests which fail in helpful ways. These should be quite fine-grained. For example, say you have a "foo" method. You might have a single test method: "testFoo" which could be all you need. Or it might be better to go into more detail. Say it takes an integer arg. You might want to write tests:
    - testFooWithParameterZero
    - testFooWithParameterOne
    - testFooWithParameterGreaterThanOne

    In mathematics, zero and one are often special cases and, you might obtain an inductive proof for a theorem by proving for zero, one, and then for any number greater than one. I'm really just making a general point rather than recommending that every method which takes an integer parameter has to be tested this way. Exactly what you should test depends on the class in question. Fine-grained tests can lead to more failures but each failure should be a useful piece of information which ought to help to fix the problem. A failing "testFooWithZeroParameter" could be more helpful than a failing "testFoo".

    There's definitely an art to this. As well as creating constraints for possible implementations, tests act as guides to help you fix failing code. They're also a source of documentation. Good method names and small test methods might help to achieve all that.

  14. #39
    SitePoint Enthusiast silicate's Avatar
    Join Date
    Nov 2004
    Location
    Toronto
    Posts
    43
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hey,

    Thanks for your post, it gave some good pointers. I also downloaded the inputcontroller since there was some mention of tests in that. I assumed it wouldbe a good source of "best practices" regarding testing.

    Even though it isn't that involved testing-wise one thing helped was the use of the "optional description" :

    Code:
    $this->assertEqual($Person['sex'], 'Female', 'sex:'.$Person['sex'].' should be Female');
    That is far more readable than the standard return, mostly 'cause I am not used to reading it I guess. Maybe I am just trying to sneak in my old "echo" habits though?

    Later,

    Matthew.

  15. #40
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I find I hardly ever use custom messages in tests - I'm not really sure what other people do. In the example you gave, a failing SimpleTest assertion will tell you what the two values are so you could leave the custom message out if you wanted. In general, it's probably better to strip things down to make them as simple as you possibly can.

  16. #41
    ********* 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 silicate
    One thing that I was wondering - and this relates to the subject of this post - is it is possible to have a test depend on another one passing? It's kinda annoying (and distracting) to get a whole set of errors because a method that is used by other methods fails.
    This is getting into more advanced territory. You can decouple unit tests with mock objects. The decouple tests well. So well, that you may need a few conventional integration tests just to make sure that everything is talking to each other just the way they should.

    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
  •