Test Development - Unit Testing (in CakePHP)

Question

I had some problems with unit testing in CakePHP, especially when testing database insert / update. Let's say I have a model, something like this:

class User { var $name = 'User'; function updatePassword($data) { return $this->updateAll($data); } } class UserTestCase { function testUpdatePassword() { $tmpData = array( 'User' => array( 'password' => sha1(uniqid('', true)) //dummy pass ); $result = $this->User->updatePassword($tmpData); $this->assertTrue($result); } } 

The problem is that in my test case:

• I have to provide dummy data that is usually extracted from forms
• The dummy data format does not take into account the fact that the actual form data may be incorrect
• I am only testing if this update is successful: it seems like a lot of effort is needed to create all the dummy data to verify this

This example may seem a little far-fetched (I could do an update in the controller without creating, for example, an additional model method), but the main thing is that when testing updates / inserts, the data is dummy data and the data received from the forms may differ, and the benefits do not seem to outweigh the costs.

Your approaches to TDD and unit testing are appreciated, and it will be a pleasant idea of ​​what type of coverage you usually try to provide in business.

Greetings

Answer 1

Someone said that unit tests should tell a story. This approach can help you write tests that make sense in terms of coding the application. Write descriptive names for each test method, for example:

 function testUpdatingInsecurePasswordShouldFail() { $data = array('User' => array( 'password' => 'password' )); $result = $this->User->updatePassword($data); $this->assertFalse($result); $data = array('User' => array( 'password' => '' )); $result = $this->User->updatePassword($data); $this->assertFalse($result); } 

By telling the “history” of insecure passwords, you can then write the model code so that the new test passes. Another example:

 function testUpdatingStrongPasswordShouldSucceed() { $data = array('User' => array( // forget about hashing for the moment 'password' => 'battery hoarse collect maple' )); $this->User->updatePassword($data); $result = $this->User->find('count', array( 'conditions' => array( // making some assumptions about the test data here 'User.username' => 'test_user1', 'User.password' => 'battery hoarse collect maple', ), ); $this->assertEqual($result, 1); } 

Please note that we are doing a bit more work to make sure that the update works correctly. When the testing environment begins to collect errors and regressions, you will be glad that you made additional efforts.

One of the advantages of good descriptive test names is that we can now use the cake test --testdox to display the results in plain English:

 [x] Updating insecure password should fail [x] Updating strong password should succeed 

Answer 2

TDD benefits for me (as soon as you completely wrap your head):

• I can debug my code without a browser
• If my code depends on different parts of my code, and I (or someone else) make changes that accidentally break what I checked earlier, my automatic unit tests will immediately realize that
• (personal) Changes my mindset to data entry - instead of manually entering data into a text field, I start thinking about input that can come from a script rather than a browser - really makes me focus on more secure input
• Automatic testing - as soon as the system is completed, I can run all my tests and run them in seconds to make sure that everything works, and not try to start the entire system manually, which can take several hours, depending on complexity.

Answer 3

ddawber

You indicate three points:

1.

I have to provide dummy data that is usually retrieved from the Form

You should look into CakePHP fixtures

2.

The dummy data format does not take into account the fact that the actual form data may be incorrect

These forms are checked for compliance with the model validation rules, see here .

3.

I just check, the update succeeds: it seems like a lot of effort to create all the dummy data to verify this

Then you just need to solve it by writing a test method (and you only select the appropriate cases), taking into account 1. and 2. .. Perhaps you are interested in the fact that CakePHP developers are switching from simpletest to phpunit in version 2.0, which may help you when planning your efforts.

A good trip to CakePHP testing center anyway.

Edit0: The fourth point on code coverage seems controversial. If you went for 100% coverage, you would have to write a lot of piece objects, just to make sure that the action of the controller is actually called when you call it. Writing something like this is a task for the developers of the framework, and to omit writing extra code of this kind directly affects the coverage of the code.