On Wed, Jan 21, 2009 at 7:31 PM, Eric Butera <eric.butera@xxxxxxxxx> wrote: > On Wed, Jan 21, 2009 at 7:24 PM, Murray <planetthoughtful@xxxxxxxxx> wrote: >> I think this is my problem -- basically to know how to get some benefit from >> it. >> >> If I have a function in a class that is supposed to return some rows, how >> would I go about performing a useful unit test on it? In theory (and in my >> current practice), I can simply dump the array or object, or step through >> the code with XDebug in Netbeans PHP (love this app!) to see what is taking >> place. >> >> Where would a unit test come into this process in a useful way? Is it >> because I can abstract the call to that function / class without having code >> that puts it to the page? Some other benefit? >> >> M is for Murray >> >> >> On Thu, Jan 22, 2009 at 10:13 AM, Eric Butera <eric.butera@xxxxxxxxx> wrote: >>> >>> On Wed, Jan 21, 2009 at 7:01 PM, Murray <planetthoughtful@xxxxxxxxx> >>> wrote: >>> > Hi All, >>> > >>> > I'd like to understand unit testing better (or, in fact, at all). I >>> > understand the broad idea that testing Is A Very Good Thing, but when I >>> > have >>> > tried to look into it further (for example, have just been looking >>> > through >>> > the PHPUnit site), I always end up thinking 'This looks like more >>> > trouble >>> > than it's worth.' I'm sure that's down to me and not the process of unit >>> > testing, but I'd like to get some idea of how people on the list >>> > actually >>> > use unit testing in the real world. >>> > >>> > I'm assuming that you have your actual application classes and functions >>> > designed in their own files, and then you build a series of unit testing >>> > classes / functions in their own sort of space, but do you build these >>> > in >>> > parallel to your application code, or during alpha / beta testing etc? >>> > >>> > Any practical or even theoretical advice welcome! >>> > >>> > Many thanks, >>> > >>> > M is for Murray >>> > >>> >>> Well this was a hard topic for me to grasp too. A lot of times I >>> still get lazy about it, but I strive to do my best. Unit testing >>> makes sure your code works as expected. So if you're messing around >>> with stuff, keep re-running your test suite and see if your changes >>> break any of your tests. This way you know whether or not your >>> changes are breaking the very apps that rely on your code. >>> >>> Unit testing also allows you to quickly assess problems with different >>> servers, php upgrades, whatever. >>> >>> Of course these are just little points. Just give it a try and keep >>> going at it. Once I started I noticed that I had been writing my code >>> all wrong. Lots of weird dependencies, reliance on hard to recreate >>> state, stuff like that. It helped me to start writing leaner methods >>> that targeted what they were supposed to do a lot better. >>> >>> There's a lot of info on this subject all across the net & in books. >>> It isn't just limited to php, but programming in general. >>> >>> V is for Vendetta? >> >> > > Think of an ecommerce app. You've got code that calculates price > based on lots of different factors. Unit testing lets you make sure > that your prices will always add up correctly based on those factors. > Too many times have I messed something up and all of a sudden Michigan > tax isn't acting right. Unit testing prevents those 4:50pm mistakes. > :D > > Start small just testing the logic of your app. Don't worry so much > about making sure a query has x data. You can do something called > mock that out later on once you've got a better handle on things. > > You might also look at established code and see their unit tests to > maybe get a better idea of how it is really useful. Really tho > oops I accidentally sent that before finishing. But you get the idea at any rate. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
