Testing framework completed

Please give it a try. If you find any problems, please let me know.

You may find the relevant documentation in the guide (/docs/guide/test.*.txt)

The blog demo also contains real test examples. And "webapp", "model" and "crud" commands will generate skeleton test code.

Thanks.

sweet!  will be trying this out soon!

btw- congrats on the community growth!  I joined when registered users were less than 68, I believe!

-Paul

Hi Qiang,

I studied the solution and have a few questions now.

  1. In your examples you show unit testing for the Model classes which are self-contained and quite simple to test.

How about testing actionIndex() method of a controller? Setting the environment there is more complex than just put specific records to the DB. Things that should be set up there are:

  • GET, POST parameters

  • running filters

  • authentication state

  • HTTP_REFERER

One may disagree on the question saying that testing this methods is more like funtional testing and should be performed with selenium. Yes, this may be a good example for functional testing, but right the same problems come out in widget testing, environment should be set up for them.

  1. There is only fixture manager for the DB fixtures, how about creating CFixtureManager, extend CDbFixtureManager from it and create CEnvironmentFixtureManager that provides initial state for the testing class. It can be loaded from the files similar to the DB fixtures. I can help with implementation if you help with designing the solution

  2. I saw you used some other approach when testing framework components. For example for url manager you created list of input params, configs for the manager and then looped through them creating the new application each time. Why didn’t you follow the approach you described in the guide?

Is the one you implemented better for the component testing? If so, could you describe how it works in details?

You have raised some very good questions.

1). Yes, I think the controller actions are better tested in terms of functional tests. Still, the current test support needs to be enhanced to better support testing other components, including widgets, application components, etc. We expect to add these support gradually.

2). This is similar to 1). In fact, the key problem of both 1) and 2) lies in how to set up the fixture easily.

3). The existing framework tests were written before this testing framework was done. When we get time, we will rewrite those tests using the new framework.

I see… So any ideas on the component design? How the environment fixture can be set up easily?

I guess, the good idea is to design it in the way so it can be used similar to provider() method in PHPUnit tests, setting up the environment for each test separately.

That should be a cool tool for quick testing, I think