Codeception Testing with Yii Framework 2.0 [Day 12]

Today’s Objective(s)

  1. Research best practices for Unit testing in Yii
  2. Research executing tests and viewing results from a browser
  3. Research best practices for acceptance/functional testing in Yii


I moved the objectives around for today (2 is now 1 and vice versa), this is because I’m not quite sure I want to worry much about executing my tests from a browser. I also think there are already implementations of this and doing it myself would be like reinventing the wheel, so I’ll modify it a bit for tomorrow to something a bit more useful.

On to the topic at hand! Best practices for Unit testing in Yii… now there seems to be varying opinions on unit testing, so I’ll make this piece my own opinion on the matter and the practices I’ll be setting out for myself to achieve.

What to Unit Test?

For Yii, I believe the only item that really requires unit testing is the models used. Yii has a fat model … model of the MVC architecture, meaning that the prime focus is to have the majority of logic inside of the model. To quote the guide:

In summary, models

  • may contain attributes to represent business data;
  • may contain validation rules to ensure the data validity and integrity;
  • may contain methods implementing business logic;
  • should NOT directly access request, session, or any other environmental data. These data should be injected by controllers into models;
  • should avoid embedding HTML or other presentational code – this is better done in views;
  • avoid having too many scenarios in a single model.

That makes models the only place to do proper unit testing from what I can tell, and then in the unit tests we mock the injections from the controller (Like user info/requests). And this in turn makes for very clean and easy to read Controllers :)

What is the best process to implement Unit Tests

MY opinion on this is create the Unit test before the actual code and then do the code. This is both an excellent form of development, since it both gives the developer pure clarity of what needs to be done, and means that further down the line the unit test can be used to ensure that nothing has broken over the course of further development (And it’s there to be used, instead of needing to make it and struggling to remember what the code is really supposed to do).

Of course keeping to this practice proves insanely difficult as I find myself constantly just going straight to the coding and only remembering the actual unit test 2-3 functions later, but I’m making a very dedicated effort to change that habit. Believe it takes a lot of trial and error to find the sweet spot where creating the unit test and doing the code becomes more useful. By this I mean that if the unit tests are too basic it could lead to multiple breaks in development to write another unit test, or the unit test could be too intricate and the resulting code could require multiple debugging sessions to get at why the unit test isn’t passing as expected.

But once that sweet spot is found, I believe it could be glorious! Saving a lot of pain and effort further down the line, so I will gladly trip and fall a few times now to allow myself to sprint uninterrupted in the future ;)

And as with all testing, shouldn’t forget to include negative cases. I’ve seen it a lot where the “Happy day” cases are focused on and “Rainy day” cases end up causing floods (heh).


Unit tests are awesome and I believe a little misunderstood. The general feel I’ve gotten about Unit tests over the years has been bad… although this might have been from my lack of understanding them. But after what I’ve learnt so far, they can mean a whole lot less trouble for just a few simple lines of ‘extra’ code.

Well worth it in my opinion :)

Upcoming Objective(s)

  1. Write a new acceptance test
  2. Research best practices for acceptance/functional testing in Yii

Ps. You will notice that I’ve now completely removed the part of the objective for running/viewing tests in the browser. Will revisit the idea after covering acceptance and functional tests. Also number 2 on the above list had a spelling mistake (pracices)… shocking :D

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>