Testing framework completed
Posted 19 June 2009 - 03:20 PM
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.
Posted 13 September 2009 - 04:27 AM
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
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.
2) 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
3) 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?
Posted 13 September 2009 - 06:51 AM
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.
Posted 13 September 2009 - 08:47 AM
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