unit testing questions

[dadamssg87]

unit testing has been mystifying me for months. I don't quite get it.

 

Are the tests just checking the data type of what the functions spit out?

 

Do they test the input? or do you define the input in the test?

 

If you define the input in the test, do you test multiple data types? i.e. strings/integers/boolean/timestamps/etc ?

[gizmola]

What you're trying to accomplish is testing units of code.  "Given X -> expect Y".  What you get from unit testing is Pass or Fail.  So if you are testing a function that takes a variety of different input options, you need to write a test case for each potential input if you want any granularity of what failed.

 

In order to do that you need to control input. So this is done either by hardcoding iput, or using fixtures, which allow you to set your environment back to known/default state. 

[dadamssg87]

i'm trying so hard, but i still don't freaking understand it. What good is a test program telling me something broke rather than the program itself telling me it broke by spitting out a php error and it will even tell me on what line? I know theres a reason and i'm trying desperately to understand it.

 

say i have a function like this. Obviously it's going to break. $x is expecting a number, not an array or string.

 

A. How would i write a test for this?

B. How would the test benefit me rather than no test and the php error tell me what went wrong?

 

<?php
$one = array('key' => 'value');
$two = 2;

//or better yet

$one = $_POST['number_field1']; // let's say they enter in "adgaklj"
$two = $_POST['number_field2']; //and "2" for this field

$addition = add_numbers($one, $two);

function add_numbers($x,$y)
{
$z = $x + y;
return $z;
}

?>

[gizmola]

I think I am starting to understand where you are confused.

 

Unit tests are not designed to find out what you don't know about how your code works, they exist to insure that what should be true, still is, even after you've changed things.  If you know in advance that an array will break your add_numbers() function, unit tests are not designed to tell you that.  Your function should handle that in a predictable manner.

[SparK_BR]

ok, let's say you have a class Car

you have a unit test for that car:

class TestCar{
    private $subject;
    
    public function TestCar(){
        $this->subject = new Car();
    }
    public function testAccelerator(){
        $oldValue = $this->subject->getSpeed();
        $this->subject->accelerate();
        
        if($this->subject->getSpeed() <= $oldValue)
            throw new Exception("Accelerator Failed");
    }
}

$unitTest = new TestCar();
$result = "It Passed";
try{
    $unitTest->testAccelerator();
}catch(Exception e){
    $result = "It Failed";
}
echo $result;

 

that's how you make a unit test

[SparK_BR]

I made a typo there

$this->subject instead of $subject when inside methods... sorry (editing time limit? :-\)

[gizmola]

I updated your original post SparK.

[ignace]

Unit-Testing is an automated process. Sure you could write code and just run it in a browser, see if any of it failed. And as your project grows and new functionality is implemented other parts might break without you knowing so to avoid it you will have to start making a checklist of your entire website, going over each one of them to make sure it still works. If one of them fails on your checklist, you alter your code to fix it, and you will have to start back from the top (since something else may have broke) going over each one of them until something else fails, again and again and ..

 

Unit-Testing automates this process. It allows you to add functionality or refactor some code without having to worry something will break, because if it does you'll know it by the push of a button.

 

That said, it means that your tests have to be thorough otherwise they are just false-positives. To ensure they are thorough you write positive and negative tests. Where positive tests check whether it works and negative tests check whether if it gets something unexpected it will fail gracefully.