thats a long post, so I can't follow everything you wrote.

But that is linked to test/fixtures/public, which is empty.

there should be

.htaccess
index.php

in /fixtures/public.

So in the end

$this->get(AK_TESTING_URL);
$this->assertResponse(200);
$this->assertTextMatch('InfolakeController:index()');

fetches a page/url and the assertTextMatch(...) matches against the returned view/response.

but

return InfolakeController:index();

wouldn't be valid php.

I meant against the view or response, so say you have a template with <h1>Hello</h1> you then fetch the page and assert

assertTextMatch('Hello');

can you point your browser to test/fixtures/public in a way?

Do you (or anyone) know how to pass strings from a controller to a view?

Look here.

What I don't know is how to make something in text/fixtures/public point to the controller that I want to test.

Actually what do you get when you point your browser to this location? (The index.php in there should do the 'point'.)

I just try to guide you. After all, when everything works, you can run your tests from the command line. I'll do.

two things.

[1.] I'm not sure you know what the AkWebTestCase is all about.

class DummyWebtestcase extends AkWebTestCase 
{
    function testShouldGetTheGoogle()
    {
        $this->get("http://www.google.com");
        $this->assertText("Google");
    }
}

run this from the command-line. it should get the google-page and search for the string "Google".

so to speak, the ->get-method is a HTTP-Get.

[2.] So "fixtures/public" needs to be public, exposed, reachable by a browser. To test this, I thought, point your browser to this dir.

You can - I did it once - configure a seperate vhost just for this purpose. then practically http://my-akelos-test/ could point/link to this dir and you should see ... yeah what do we see?

you could just test this apache-thing by putting a index.html into this dir.

ok, next thing: in fact, in this dir there should be an index.php which dispatches the Request and starts the whole Akelos Framework. But this would be the next thing. In this step we could see if the dispatcher finds the right controller etc. This is mainly a Router-thing inside Akelos.

the last step would be configure AK_URL or other constants.

I was not allowed to send a php file as an attachment, so here's the code:

echo "test/fixtures/public/index.php<br />";
$result = Ak::get_constants();
echo $result;

include_once(dirname(__FILE__).DIRECTORY_SEPARATOR.'..'.DIRECTORY_SEPARATOR.'config'.DIRECTORY_SEPARATOR.'config.php');

require_once(AK_LIB_DIR.DS.'AkDispatcher.php');
$Dispatcher =& new AkDispatcher();
$Dispatcher->dispatch();

I know that I can get to the controller originally with the URL http://server/project/controller. The default action will be the index function. The controller is to handle the importation of a CSV file. Because I have a batch task to perform, the program must route itself back to the controller repeatedly. Therefore, this index method must do different things depending upon what has happened. This controller must also allow interactive input, just as the framework is designed for.

The input method will read a record, then send it off to a standard verify routine, just as though it was entered interactively. If there are errors, the record will go to the edit method, which will be standard except that it will permit the user to skip the record if it can't be fixed. After either skipping or saving each record, action will return to the import method until EOF. The select method is where the user supplies the name of the file to be imported. It will have a link that will connect back to the listing method, from where the user can enter data interactively.

This index method is in the controller.

function index()
{
  $this->Introspekt[] = 'InfolakeController:index()';

// $this->renderAction('listing'); This line is the original code for the function. if(exist($this->csv_file)){ if(exist($this->csv_file_is_open)){ $this->renderAction('import') // At EOF, the variable called $this->csv_file will be deleted, // but $this->csv_sought will remain true }else{ $this->renderAction('open'); } $this->renderAction('index'); }elseif(exist($this->csv_sought)){ $this->renderAction('listing'); }else{ $this->renderAction('select'); $this->csv_sought = true; $this->renderAction('index'); } }

function import()
{
  $this->Introspekt[] = 'InfolakeController:import()';
}

function open()
{
  $this->Introspekt[] = 'InfolakeController:open()';
}

function select()
{
  $this->Introspekt[] = 'InfolakeController:select()';
}

In the app/view, I have files import.php, open.php and select.php. Right now, each of them just echoes the contents of Introspekt. What I want to test is that this index.php works as intended. I want to add code a bit at a time as I confirm that what I have works as intended.

As I see it, the "fake" controller should cause the "real" controller to be executed, so that I can see what is going on -- a trace, if you will.

BTW, I don't know where in the world the rest of you all are. I'm north of Helsinki, Finland. I'm between 7 and 10 hours earlier than folks I know in my native U.S.A. :-)

In vuokraten/test/fixtures/app/controllers/infolake_controller.php, I have this: [...]

in the fixtures-dir, you can't have tests. fixtures are test-controllers or are pointing to your real controllers, so they import/include them.

I'll put the tests in test/unit/app.

[...]

It ran with the command: $ ./script/test test/unit/app/controllers/dummy_web.php

but the output was followed by a bunch of session related errors, which I suppose was OK.

why are thrown errors ok?

In either case, the browser displays test/fixtures/public/index.php 404 Page not found

As I understand it, the way to resolve this is through config/routes.php.

Is this a Apache-404 or an Akelos-404? config_routes only applies when the Akelos Framework actually dispatches the request. On a real 404 or 5xx Apache-error (see your Apache log) we would have a configuration-problem.

$result = Ak::get_constants();

you call this even before including the framework. So from my understanding you really should be getting an error.

I might be stupid and I am stuck but

1. The Google-example should work
2. Put an index.html with <h1>HelloWorld</h1> into fixtures/public.
3. Adjust the 'google test', so it fetches the Testing-Url and matches HelloWorld

Then you would have a valid WebTestCase. A very simple one without controllers and fancy stuff. But a not-failing one.

Right now, I simply don't hear a clear-case for these 3 prerequisites.

Thrown errors are not OK. In this case, I got a normal result followed by the errors. I was unable to know what threw the error, but because I could see the result I wanted, I said "OK."

The 404 comes from (if I'm not mistaken) akelos/lib/AkRequest.php, at either line 763 or line 774.

I think that my basic problem is that I'm moving around in the dark. When I think that I understand where the flow of the Akelos framework is supposed to take me, I take a turn in that direction, but I bump my nose against a wall that I didn't realize was present. I need to learn the basic principles. Things have been written that give step by step instructions, but without knowing what is behind them, I can't make a needed adjustment when things don't work. Here is an example:

1. The Google-example should work. I tried to do what I had done earlier, but I must have changed something. I don't remember what it might have been, but because I don't understand the principle behind it, I have to guess how I might get it to work.

I decided to go back to the Wiki, Introducing AkUnitTest. I created test/hello_test.php and ran it from /home/alan/develop/php/vuokraten with:

.script/test  hello_test.php

I got a valid result, but with a PHP error. I checked /etc/php.ini to make certain that session.savepath indeed points to /var/lib/php/session. The files in it are all owned by apache:apache with an rw permission for the user. I restarted httpd, but this didn't clear the error. (continued after the output)

HelloTestCase
OK
Test cases run: 1/1, Passes: 1, Failures: 0, Exceptions: 0
/home/alan/develop/php/vuokraten/test/hello_test.php
PHP Warning:  Unknown: open(/var/lib/php/session/sess_14m93icat7434o2tkpe3mntpn4, O_RDWR) failed: Permission denied (13) in Unknown on line 0

Warning: Unknown: open(/var/lib/php/session/sess_14m93icat7434o2tkpe3mntpn4, O_RDWR) failed: Permission denied (13) in Unknown on line 0
PHP Warning:  Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php/session) in Unknown on line 0

Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php/session) in Unknown on line 0

I ran ./script/test test/unit/app/controllers/dummy_web.php and got the following result, a listing of the file rather than an execution of it.

    class DummyWebtestcase extends AkWebTestCase 
    {
        function testShouldGetTheGoogle()
        {
            $this->get("http://www.google.com");
            $this->assertText("Google");
        }
    }
    /home/alan/develop/php/vuokraten/test/unit/app/controllers/dummy_web.php

I think I'll just go scratch my head for a few hours. I'm bumfoozled.

I got a valid result, but with a PHP error. I checked /etc/php.ini to make certain that session.savepath indeed points to /var/lib/php/session.

Ok, this has nothing to do with functional tests. Please double-check that your editing the right php.ini, the session.savepath contents, if the directory exists, if it has the right permissions, etc.

I ran ./script/test test/unit/app/controllers/dummy_web.php and got the following result, a listing of the file rather than an execution of it.

Maybe you forgot to enclose your test between php tags?

Regards, Matías.

I'm going to start a new thread with the PHP bug, because, although the bug is in PHP, the workarounds are in the application, in this case Akelos.

Back to the test case. It seems that we have a valid test with test_hello.php and also with dummy_web.php (find Google).

In the Wiki entry for unit tests, the instructions for what to do have yet to be written. My test infolake_controller looks like this:

<?php
require_once(dirname(__FILE__).'/../../../fixtures/config/config.php');

class InfolakeControllerTest extends AkWebTestCase 
{

    function test_should_get_index()
    {
        $this->setMaximumRedirects(0);
        $this->get(AK_TESTING_URL);
        $this->assertResponse(200);
//        $this->assertTextMatch('InfolakeController:index()');
    }
}

ak_test('InfolakeControllerTest');
?>

It seems to me that one should not assertTextMatch until assertResponse is successful. Here's the test for that:

[alan@erie vuokraten]$ ./script/test unit/app/controllers/infolake_controller.php
InfolakeControllerTest
1) Expecting response in [200] got [301] at 
[/home/alan/develop/php/vuokraten/test/unit/app/controllers/infolake_controller.php line 11]
        in test_should_get_index
FAILURES!!!
Test cases run: 1/1, Passes: 0, Failures: 1, Exceptions: 0

/home/alan/develop/php/vuokraten/test/unit/app/controllers/infolake_controller.php

My AK_TESTING_URL is http://alan.lakeinfoworks.com/framework_tests/test/fixtures/public. When I put that in my browser, I get a blank page except for the text: 404 Page not found.

The only place that I see that message in that format in the Akelos source is in akelos/lib/AkRequest.php, in this code:

    if(@!include_once($controller_path)){
        if(AK_ENVIRONMENT == 'development'){
            trigger_error(Ak::t('Could not find the file /app/controllers/<i>%controller_file_name</i> for '.
            'the controller %controller_class_name',
            array('%controller_file_name'=> $controller_file_name,
            '%controller_class_name' => $controller_class_name)), E_USER_ERROR);
        }elseif(@include(AK_PUBLIC_DIR.DS.'404.php')){
            exit;
        }else{
            die('404 Page not found');
        }
    }
    if(!class_exists($controller_class_name)){

        if(AK_ENVIRONMENT == 'development'){
            trigger_error(Ak::t('Controller <i>%controller_name</i> does not exist',
            array('%controller_name' => $controller_class_name)), E_USER_ERROR);
        }elseif(@include(AK_PUBLIC_DIR.DS.'404.php')){
            exit;
        }else{
            die('404 Page not found');
        }
    }

I checked the value of AK_ENVIRONMENT. It is "testing".

What to do about it is still beyond me.

In Bermi's response to Tom (at the beginning of this thread), he said You need to make your test/fixtures/public folder visible on your web server.That is what http://alan.lakeinfoworks.com/framework_tests/test/fixtures/public does.

I have another symlink that goes to vuokraten/public. This starts my application, but not as a test.

When I start my test, action goes to test/fixtures/public/index.php. This creates a $Dispatcher object from the Akelos/lib/AkDispatcher.php file. It then executes $Dispatcher->dispatch, which executes $this->Request =& AkRequest(); $this->Controller =& $this->Request->recognize();
In that code is an attempt to include_once test/fixtures/app/controllers/page_controller.php. Because there is no such file and AK_ENVIRONMENT == "testing", the task executed die('404 Page not found'); on line 763.

Who knows why it requires test/fixtures/app/controllers/page_controller.php? I thought that perhaps it should have been looking for test/fixtures/app/controllers/infolake_controller.php, because I do have one of those. I put an entry in config/routes.php, but that didn't help. Perhaps I need a test/fixtures/config/routes.php, but there isn't one in the Akelos tree.

There is a test/fixtures/app/controllers/page_controller.php in the Akelos tree, so I made a copy of it in my project. The two methods in it are empty. Does anyone know what should Of course, I'll need a test/fixtures/app/views/ for the page methods. I copied index.tpl and setup.tpl over from akelos/test/fixtures/app/views/page. Index.tpl has only a placeholder in it. Setup.tpl has the same "Welcome Aboard" code that is in app/views/page/index.tpl. This doesn't seem to be appropriate because tests should be run from the command line.

Can someone shed some light on this situation while I get some shut-eye? Thanx.

Now you're up and running.

As I understand you placed a controller (the page_controller) and a dummy view (from our framework-tests) into the fixtures folders. So that when you invoke the index action on the page controller it renders the view which only consists of the string "Test::page::index".

That isn't very informative but I hope we can work it out.

AkRequest defaults (hard-wired via the constants AK_DEFAULT_CONTROLLER & AK_DEFAULT_ACTION) to a so-called page-controller if no set route matches. So I assume you're trying to

->get(AK_TESTING_URL)

which points to fixtures/public. This is kinda the root of the public folder. Just like

->get('http://my.url.com/")

would be.

->get(AK_TESTING_URL.'/infolake')

should be delegated to the infolake_controller (and the index action).

You could set up the config/routes.php so that '/' gets delegated to the infolake_controller

$Map->connect('/', array('controller' => 'infolake', 'action' => 'index'));

Akelos/lib/AkDispatcher.php has a comment at the beginning that I'd like to ask about because it may help in the solution to this problem. It says @deprecated Please use AkDispatcher on your public/index.php instead Yet, my test/fixtures/public/index.php calls this one with this line: require_once(AK_LIB_DIR.DS.'AkDispatcher.php'); I don't have an AkDispatcher in my test/fixtures/public directory. Perhaps I should have a copy of AkDispatcher there that would be slightly different than the one in Akelos/lib. That difference might go to the test that I want instead of to the page controller.

I've begun a new project, which seems to have a different directory structure in the test section. Let me work at the new project functional test, then bring this one into compliance with it. I'll make another post...

Got a similar problem as alake: When I point web browser to the test/fixtures/public directory with only .htaccess and index.php (without any modifications to them), the message '404 Not found' is displayed. It comes from AkRequest.php, line 738. As alake identified already, the framework is looking for the page controller test/fixtures/app/controllers/page_controller.php which is not available. If it is copied to that location from project/app/controller/, the following error is displayed in the browser instead:

 Warning: Missing template /home/jm/linux-projects/pt/test/fixtures/app/views/page/index.tpl
 in /usr/local/web/akelos_framework/lib/AkActionController.php on line 986

 Fatal error: No tpl.php, js.tpl or delegate template found for
 index in /usr/local/web/akelos_framework/lib/AkActionView.php
 on line 231

So can anyone please explain to me what must be configured for the browser access to tests to work properly? BTW, I have successfully created and run the dummy_web.php test from the command line, the same for hello_test.php.

I don't use a virtual server, instead symlinks were created: DocumentRoot/project -> DevDir/project/public and DocumentRoot/project_test -> DevDir/project/test/fixtures/public.

The directory DevDir/project/test/fixtures/app/controllers does not exist nor any templates in the test tree. OK, now I have created a simple controller DevDir/project/test/fixtures/app/controllers/device.php:

  <?php
  class DeviceTestCase extends AkWebTestCase
  {
      function testShouldGetTheGoogle()
      {  
          $this->get("http://www.google.com");
          $this->assertText("Google");
      }
  }
  ?>

Not sure if this is appropriate as a test run via browser or how it should be invoked.

The file test/fixtures/public/index.php is what has been created by the framework:

 <?php
  include_once(dirname(__FILE__).DIRECTORY_SEPARATOR.'..'.DIRECTORY_SEPARATOR.'config'.DIRECTORY_SEPARATOR.'config.php');

  require_once(AK_LIB_DIR.DS.'AkDispatcher.php'); 
  $Dispatcher =& new AkDispatcher();
  $Dispatcher->dispatch();
  ?>

I am not sure what is supposed to happen, my expectation was that the dispatch would rn the unit tests or something like that.

Thanks Kaste for your comments, I can see some light at the end of the tunnel now even though I am still now out of the darkness.

You say that the 'testcases are run from the command line', when do you suggest using the browser to run tests (and what kinds of tests)? The command line execution of tests works fine for me.

Your mention that the generators should create some dummy testcases in test/functional/controllers made me to look again at what I did and found an interesting discrepance in the use of the generators. I used ./scripts/generate model Device ./scripts/generate scaffold Device because the help claimed the scaffold generator creates controller scripts if they don't exist. But they have not put anything in test/functional/controllers. For example:

  $ ./script/generate scaffold Lap
  The following files have been created:
  /home/jm/linux-projects/pt/app/models/lap.php 
  /home/jm/linux-projects/pt/app/installers/lap_installer.php
  /home/jm/linux-projects/pt/test/unit/app/models/lap.php 
  /home/jm/linux-projects/pt/test/fixtures/app/models/lap.php
  /home/jm/linux-projects/pt/test/fixtures/app/installers/lap_installer.php
  /home/jm/linux-projects/pt/app/controllers/lap_controller.php
  /home/jm/linux-projects/pt/app/helpers/lap_helper.php
  /home/jm/linux-projects/pt/app/views/layouts/lap.tpl
  /home/jm/linux-projects/pt/app/views/lap/add.tpl
  /home/jm/linux-projects/pt/app/views/lap/destroy.tpl
  /home/jm/linux-projects/pt/app/views/lap/edit.tpl
  /home/jm/linux-projects/pt/app/views/lap/listing.tpl
  /home/jm/linux-projects/pt/app/views/lap/show.tpl
  /home/jm/linux-projects/pt/app/views/lap/_form.tpl


  $ ./script/generate controller Device
  The following files have been created:
  /home/jm/linux-projects/pt/app/controllers/device_controller.php 
  /home/jm/linux-projects/pt/app/helpers/device_helper.php
  /home/jm/linux-projects/pt/test/functional/controllers/device_controller.php
  /home/jm/linux-projects/pt/test/fixtures/app/controllers/device_controller.php
  /home/jm/linux-projects/pt/test/fixtures/app/helpers/device_helper.php

There is obviously (now) a difference in what stubs get created depending on generator options. What is the most recommended aproach to generating the stubs? Is it

  ./scripts/generate model Device
  ./scripts/generate controller Device

and not the scaffold?

BTW, I have replaced test/fixtures/public/index.php with a link to test/app.php and now the web browser shows the output of all tests.