James Pic wrote:
> eZ component: Framework, Requirements
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> Introduction
> ============
>
> eZ Components were developed in the spirit of letting a maximum of freedom
> to the user. A new component restricting the freedom of the developer might be
> interesting if it can make developpement of applications even faster.
> Terms of "feedom restriction" were chosen to oppose the existing components to
> the one that will be described : it should reduce the quantity of strategical
> choices that the programer has to make in order to save time, but still be
> able to solve any kind of problem.
>
> Frameworks aim to help the user to develop an application faster and
> sometimes, with more reliability.
> There are many kinds of frameworks out there on internet. But where are the
> frameworks proposing a real test-first environement ?
> The component "framework" should provide ready-to-use test-cases to allow
> really fast and reliable test-first developement.
>
> It's possible to make the developpement faster by :
> * less thinking of deciding the structure of the application.
> * generating applicative code.
>
> It's possible to make the maintenances and updates easier by :
> * providing a test-first complete environement.
>
>
> Description
> ===========
>
> The framework component aims to reduce developement and maintenance time by
> providing :
> * code generators,
> * a common web-application design, able to solve any problem,
> * a complete test-first high-level environment.
>
> Requirements
> ============
>
> It should provide :
> * a basic project directory generator.
> * test-runner(s) and case(s) to make faster test-first at the framework-user
> level :
> * provide a dbunit-like system,
> * provide methods to set arbitary data to eZC-level objects,
> * provide eZC-level object shunts.
> * new persistent object generator : documented and using overloading methods
> to throw exceptions when a property is set with a value that isn't compatible
> with the database column.
> * a testcase extension generator able to :
> * use the dbunit-like system to make the pesistent object's test methods,
> allowing the framework user to start hacking the generated code as soon as
> generated.
> * make controllers or action testcase skeletons.
> * provide controllers and/or a controllers generator for :
> * user authentication and permissions management,
> * persistent object CRUD.
> * generators should provide test-cases to allow the user to start hacking the
> generated code.
>
> Design goals
> ============
>
> Generators should always generate tests for the generated code.
> It should be easy to add generators in later releases.
> The framework should be able to solve any web-application common problem.
>
> The ez-test-first concept :
> Presentation of the concept/procedure to create a simple action :
> * extend the action TestCase and make the test of the first action.
> * use the runner to run the test, which should fail since the action hasn't
> been programmed.
> * program the action until the test passes.
>
> If the first action is : update the persistent object using the query's post
> variables if the user is authenticated. The tests could look like :
> class UpdateWidgetWithRegularPostDataTest extends ezcFrameworkActionTestCase
> {
> public function setUp()
> {
> // parent::setUp();
>
> /*
> * All the code parent to the action should be executed for
> * the revelency of the tests.
> */
> $this->setClientRequest(
> array(
> 'id' => 1,
> 'colour' => 'blue'
> );
> );
>
> /*
> * Hard-set the action, for all the code executed before the
> * action.
> */
> $this->setAction('updateWidget');
>
> /*
> * This tests require the Widget's table(s) to be set up in a
> * temporary database.
> */
> $this->dbunit->prepareTemporaryDatabaseWithPersistentObject(
> 'Widget'
> );
>
> /*
> * This test requires one Widget fixture in the database.
> */
> $this->dbunit->addPersistentObjectFixture('Widget');
> }
> /*
> * The action should not be executed by unauthenticated users.
> */
> public function testUserNotAuthentified()
> {
> /*
> * Hard set the action requester to a guest-user
> */
> $this->setVisitor($this->guest);
>
> try
> {
> $this->runAction();
> }
> catch ( ezcFrameworkNoPriviledgesException $e )
> {
> return true;
> }
>
> // no exception was catched.
> $this->fail();
> }
>
> /*
> * The action should update the database-fixture
> */
> public function testObjectUpdatedCorrectly()
> {
> /*
> * Hard set the action requester to an authorized user
> */
> $this->setVisitor($this->authorized);
>
> $this->runAction();
>
> // assert that the action successed
> $this->assertTemplateVars(
> array(
> 'message' => 'success',
> ),
> 'Action should be successfull since the request is
> fine and the user is authorized'
> );
>
> $this->assertEquals(
> $this->dbunit->Widgets( 1 )->colour,
> 'blue',
> 'Widget database fixture should be updated according
> to the query'
> );
> }
>
> // etc ....
> }
> The framework-user should then develop his action until his test-case passes.
> This was just an example and should be considered as-it.
> The ez-test-first solution provided by the framework should allow the
> framework-user to work in a reliable and complete environement, allowing to
> reduce HTTP-client side testing as much as possible.
>
> The framework component should provide a simple controller system, making it
> easy to develop actions (as controller methods or other classes) using common
> modern websites features : user management, HTTP query management ...
>
> NOTE: Maybe the generators, the framework and the test-first-environement
> could be
> used individually. Allowing the user to generate a CRUD controller or uthe
> test-cases for faster and easier test-first.
>
Hi James,
Thanks for submitting your proposal. Some of my comments:
- How is your component going to relate to UnitTest? Inherit the test
runner and test case? Or totally different classes?
- How does your component relate to our own "Framework" component (if we
will ever make it)? Is it a part of it? Or inherits from it?
- Can some or all of your ideas be implemented in UnitTest instead of
creating a new component? For example PHPUnit can generate skeleton
classes for tests, why not extend it to generate controllers and action
testcases? And the other functionalities as well.
Cheers,
Alex.
--
Alexandru Stanoi
eZ Components System Developer
eZ Systems | http://ez.no
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
