Types of testcases in PHPUnit

Question

I am new to PHPUnit, infact I started today. And, as far as I have been reading, I came to understand only what this script does.

class UserTest extends PHPUnit_Framework_TestCase
{
     protected $user;

    // test the talk method
    protected function setUp() {
        $this->user = new User();
        $this->user->setName("Tom");
    }

    protected function tearDown() {
        unset($this->user);
    }

 public function testTalk() {
        $expected = "Hello world!";
        $actual = $this->user->talk();
        $this->assertEquals($expected, $actual);
    }

}

For this class:

<?php
class User {
    protected $name;

    public function getName() {
        return $this->name;
    }

    public function setName($name) {
        $this->name = $name;
    }

    public function talk() {
        return "Hello world!";
    }
}

Ok, so I have established that the test returns a Ok/Fail statement based on the equality of the test, but what I am looking for is more. I need an actually ways to test a more complex class that, its outcome, un-like in this example can not be guessed easily.

Say, I write a script that does polling. How would, or in what ways can I test if the methods/classes can work? The above code only shows if a methods outcome will only be 'Hello World' But, that is too easy thing to test, because I need to test complex things and there aren't much tutorials for that.

It's a pretty open ended question, because you're not providing any specifics of what you want to test: if you write a script that does polling, then you design the script in such a way that it makes it easy to write test cases for individual components/functions/methods of that script; and write the tests accordingly, mocking the other components where necessary. TDD: design the basic functions that you'll need; write the tests; then write the code; so design the code with testing in mind — Mark Baker, Aug 10 '13 at 18:41
So, your test should be either using the class methods to fill the poll, or use front-end plugin such as selenium to test the user experience, if actually your front end communicates with your logic at its best — Royal Bg, Aug 10 '13 at 18:43

score 6 · Answer 1 · edited Aug 12 '13 at 05:30

Testing a class in a unit test is supposed to NOT be complex.

And the reason for this to be true is that in a well designed system, you can test that class in isolation, and do not add the complexity of the system behind that class - because that system does not exist during the test, it is mocked.

The classic example for this is that a User class usually asks a database for info, but in the test case, that database is really hard to set up, prepare with data, and destroy afterwards. And using a real database also slows things down. So you design the User class to accept a database object from the outside, and in the test case you give to it a mock object of the database.

That way, it is really simple to simulate all kinds of return values from the database, and additionally you can check whether the database object gets the right parameters without the complexity of dealing with a real database.

You can only do proper mock object injection if your classes are designed to allow dependency injection. That is a principle to NOT create objects inside of other objects, but require the outside world to supply them. Just have a quick look at some video for explanation:

Dependency Injection - Programming With Anthony (Jan 2013)

And remember that creating good tests needs some experience. Good for you to start experimenting.

score 3 · Answer 2 · edited May 23 '17 at 10:31

But, that is too easy thing to test, because I need to test complex things and there aren't much tutorials for that.

The more complex, the more complex the tests are. It's a bit like a snake biting in its own end. You normally want to prevent that, so to make it golden: Write simple tests to ensure that a complex software is tested and runs.

This does not always work 100% but it works better than without tests. PHPUnit has been designed for Unit-Tests (Xunit test patterns) but you can also use it to run different tests. For that you group tests. This is done differently by different people depending on different things. For example:

Small tests
Medium tests
Large tests

or (not equivalent):

Unit tests
Integration tests
Acceptance tests

or (perhaps equivalent TestPyramid):

Unit tests
Service tests
UI tests

and what not. When you start with testing, it's probably good to start with the unit-tests and as Sven already answered, keep them simple. Get comfortable with TDD, read some slides and books. And welcome to the world of automating tests.

What is Unit test, Integration Test, Smoke test, Regression Test?

P.S. Yes, simple getter setters are too easy to test. If all a setter does is storing to a private member and the getter gets it back, you can trust that PHP is working, writing a test for that is a waste of time and will only lead to cruft. It clearly shows that somebody wrote the test after the code has been written. Instead write first the test and see it fail (red), than hack together the code as quick as possible to get the test to pass (green). You can improve the code later on as the test already shows it's working.

Types of testcases in PHPUnit

2 Answers2