Suppose there is a class. With two methods.

function getId($string) { /*Проверяем строку на валидность и если все окей, пишем ее в свойство класса*/ $this->id = $string; } function buildUrl() { /*Проверяем наличие свойства и строим URL для доступа к чему-то там...*/ if ($this->id) {/*бла-бла-бла*/} } 

Now the question. When covering tests, what should I pass on to methods? What they expect to ideally take? That is, a valid string in the first case and a non-empty property in the second.

Or what they do not expect? Any non-valid nonsense in the first case and the lack of properties in the second.

Or two tests, one for the expected parameters, and the second for the unexpected?

PS I just understand testing, so I’m not good at the hardware.

PPS If this is important, then in case of success, methods give true , and in case of failure, they throw Exception . Because, with the wrong parameters to continue the execution of the script does not make sense.

    1 answer 1

    Tests should cover the functionality of the module in various typical scenarios, both positive and negative. Class methods must return the expected values, or react as expected when passing the wrong types to the input, for example, throwing the expected exceptions. You gave a fairly simple example, you can come up with not so many scripts for testing. But in more difficult situations, you should provide less obvious varian. For example, passing an argument to the method of the correct type, but not correctly configured. Tests should cover most of the program execution branches, the more important the module, the more complete the coverage should be. It is also worth covering tests with typical scenarios of interaction with other modules of the system. IDEs such as PhpStorm are excellent at helping you navigate where the code points are not covered by tests. Later, with each bug found and fixed, add a test that will catch such errors. Plus, when writing tests, all the dependencies of the modules from each other perfectly pop up, so the tests are likely to half-crash and refactor individual modules and help you to design your classes more correctly. Poorly designed classes are almost always difficult to cover with normal tests without dragging a sheet from the extra dependencies with them into the tests.

    UPD. Example for your class

     // $this->aClass - содержит экземпляр вашего класса public function testGetById() { $this->assertTrue($this->aClass->getById('validString')); } /** *@expectedException Exception */ public function testGetByIdThrowsException() { $this->aClass->getById(null); } public function testBuildUrl() { $this->aClass->getById('string'); $this->assertTrue($this->aClass->buildUrl()); } /** *@expectedException Exception */ public function testBuildUrlThrowsException() { $this->aClass->buildUrl(); } 

    Note the @expectedException annotations. You can read more here: https://phpunit.de/manual/current/en/writing-tests-for-phpunit.html#writing-tests-for-phpunit.exceptions

    Again, given that the example is simple, then the tests are not particularly interesting.

    • Well, I understand that. But how to write a test for these functions? That is, we pass the correct parameter and check the output, then the wrong one and check the output and so on? Simply, all the examples that I came across are “Let's check how the function multiplies two by two,” and I want to look at a real example, even if it is a simple one. - qtm
    • one
      added an example for your class - Igor Karpenko
    • Oh, so many thanks for that. I will take as a template. Learn ) - qtm