I'm taking over a project and am trying to write some tests for CodeIgniter to run on the command line with continuous integration and there seem to be very little documentation online on testing with CodeIgniter and getting tests to run for controllers seem particularly difficult.
There's some previous answers suggesting to use FooStack, but FooStack is for CodeIgniter 1.x as best as I can gather.
I'm at the point not where I'm considering running selenium over the whole site. Has anyone managed to test controllers with CodeIgniter?
Related answers:
How to test controllers with CodeIgniter?
Using my-ciunit.
Grab a copy of https://bitbucket.org/kenjis/my-ciunit
Install PHPUnit 3.7.x
Run the installation instructions.
Presumably you didn't name the dadabase on the command line so go to application/config/testing.database.php and name your database with _test
Create your database.
Go to the tests folder and delete all the folders except controllers. All these files are examples and obviously you won't have those fixtures.
You only need the SomeControllerTest.php as a starting point. Edit it to hit a controller you actually have. I wanted to just add a basic access test.
class HomepageControllerTest extends CIUnit_TestCase {
public function setUp() {
$this->CI = set_controller('homepage');
}
public function testIndexController() {
$this->CI->index();
$out = output();
$this->assertNotEmpty($out);
}
}
I wrote two articles on testing Codeigniter both Unit and Acceptance tests. I use PHPUnit and Selenium for that.
Here are the links:
Unit tests: http://taiar.com.br/2013/11/08/testing-codeigniter-applications-with-phpunit/
Acceptance tests (Selenium): http://taiar.com.br/2014/04/21/acceptance-tests-on-codeigniter-with-phpunit-and-selenium/
I'm planning to write an article on tests at all (with testing theory) but my two first articles should help!
Related
Is there any way of integrating codeception into laravel that i can use it in my Controllers?
For instance let's assume I've got a route Route::post('/plugins/test', PluginController#test_plugins)
In my PluginController class I want to test whether my app works correctly or not. In my case, I wanna check this after updating a plugin by using the same semantics for acceptance tests in codeception, something like:
public function test_plugins(){
$I = new AcceptanceTester($scenario);
$I->wantTo('check that ... ');
$I->amOnPage('/plugins');
$I->seeInDatabase( ... );
....
return "site works (not) correctly";
}
I am using Laravel 4.2
Cheers
Jakob
I think you are trying to do it in the wrong way. Controller never should test anything. Controller is a thing that just know what to do when the route were called. This means that you may want to call console command from the controller which will run your tests but not write testing code in controller itself.
So the steps to achieve what do you want to do are:
Create test suit as usual in your tests folder
Create the controller
Call the ./vendor/bin/codecept run unit YourTestCest
I'm developping an acceptance test with Codeception Laravel 5.
I see in the docs that module Laravel 5 should not be used in acceptance tests.
Now, I would like to use function like: Auth::xxx, factory(User::class)->create(), etc... but those functions are not recognized.
I can use them in my funcional tests, because I include Laravel 5 Module.
Does it mean I will not be able to use them in acceptance test, or is there a trick to do it???
The documentation clearly outlines the answer to your question:
You should not use this module for acceptance tests. If you want to use Laravel functionality with your acceptance tests, for example to do test setup, you can initialize the Laravel functionality by adding the following lines of code to your suite _bootstrap.php file:
So this is what you add:
require 'bootstrap/autoload.php';
$app = require 'bootstrap/app.php';
$app->loadEnvironmentFrom('.env.testing');
$app->instance('request', new \Illuminate\Http\Request);
$app->make('Illuminate\Contracts\Http\Kernel')->bootstrap();
This means you can use the Laravel functionality in your Acceptance Tests, however, you can't use the Codeception Laravel 5 module for your Acceptance Tests.
Hopefully this clears things up.
When in acceptance testing, you have two instances, yours (codeception) and the app's (website).
This means anything laravel you use in your instance won't work in the app's instance.
Here Auth::check() has no meaning, as acceptance testing must be decoupled from the app. You should assert if you are seeing Log In or Log Out in the rendered html for example.
Eloquent is the only thing you can get away with when in acceptance testing.
i'm using Protractor and Jasmine and would like to organize my E2E test in the best way.
Example:
There is a set of the tests for check registration function (registration with right credentials, register as existed user, etc.).
I need to run those tests in three different projects. Tests are same, but credentials are different. For one project it could be 3 fields in the registration form, in another one - 6.
Now everything is organized in a very complicated way:
each single test is made not as "it" but as a function
there is a function which contains all tests (functions which test)
there is a file with Describe function in each
in that file there is one "it" which call the function which contains all tests
there is test suite for each project
I believe that there is a practice how to organize everything in a right way, that each test was in own "it". So will be happy to see some links or advice.
Thank you in advance!
Since it's a broad question, i will redirect you to few links. You should probably be looking at page-object model of Protractor. It will help you simplify and set a standard to organise your tests in a way that is readable and easy to use. Here's the link to it as described by Protractor team.
page-object model
However if you want to know why do we need to use such a framework, there are many shortcomings to it, which can be solved by using such framework. A detailed explanation is here
shortcomings of protractor and how to overcome them
EDIT: Based on your comments i feel that you are trying make a unified file/function that can cater to all the suites that will be using it. In order to handle such things try adding a generalised function (to fill form fields in your case), export that function and then require it into your test suites. Here's a sample link to it -
Exports and require
Hope this helps.
We are creating a RESTful API using CodeIgniter and I'm trying to determine how to create tests for the controllers. The controllers take some input from a client app, perform some business logic using one or more models, then output JSON.
The purpose of the tests is primarily regression testing-- to make sure that client-side engineers who are not principally web/php developers don't break something if they need to touch server code.
How would you test a controller action in CI?
I currently have two ideas:
1.) Create a test function/class that does its setup with the database then calls the controller via curl, simulating the behavior of the client.
2.) Don't test controllers, keep all logic in the models and write tests for the models.
Any thoughts on which will be more robust/easier to use? (or additional suggestions?)
As well as CodeIgniter's own testing library (CodeIgniter 2) it is possible to use PHPUnit with CodeIgniter with FooStack. If you're using CodeIgniter 2.x, it's not as straightforward to integrate as it was in CodeIgniter 1.x but I have seen it done.
FooStack itself comes with example tests covering both models and controllers, among other things, and can give you a good starting point.
Another way to test your controller, which you've said is returning JSON, might be to use the Selenium IDE. This would allow you to run simple tests that check the required input returns the expected output without worrying how it's done. FooStack or the unit testing library would probably give you a more coverage and confidence though.
If you want quality testing you need both.
One to test your code and how it handles with errors
and one to test how client itself would see potential issues.
You can validate controller also through passing the form data to your test controller like
$_POST['name'] = 'testuser';
$this->CI->index_post();
$data = output();
# Decode Response data
$actualArray = json_decode($data, true);
$this->assertNotEmpty($actualArray['status'], 'Status is empty');
like this you can validate your controller through your test/controller.
I am testing my routes in an mvc app. I have the following code:
using System.Web.Routing;
using MvcContrib.TestHelper;
using NUnit.Framework;
using web;
using web.Controllers;
namespace tests.web.Routes
{
[TestFixture]
public class routeTests
{
[Test]
public void Route_POSURL_MapsToPOSIndex()
{
MvcApplication.RegisterRoutes(RouteTable.Routes);
"~/POS".ShouldMapTo<POSController>(x => x.Index());
}
[Test]
public void Route_POSGetItem_MapsToPOSGetItem()
{
MvcApplication.RegisterRoutes(RouteTable.Routes);
"~/POS/GetItem/12345".ShouldMapTo<POSController>(x => x.GetItem());
}
}
}
However, the 2nd test fails stating:
System.ArgumentException: A route named 'Default' is already in the route collection. Route names must be unique.
If I run either test individually they run fine. Obviously NUnit is sharing my Routing table across tests. Why?
I know I can put my RegisterRoutes call in a TestFixtureSetup method but this doesn't answer the issue and I'd like to know what I am missing.
Am I just missing something? How come I can't find this question anywhere else on the net?
Thanks!
Matt
I don't think it's NUnit sharing the routes - I do believe that is how ASP.NET MVC works. FWIW, when testing my routes I usually put RegisterRoutes in [TestFixtureSetup]. You'd probably be okay to just do the same thing.
I found this great article from Martin Fowler which explains what is going on:
http://martinfowler.com/bliki/JunitNewInstance.html
Kudos to the xUnit Test Patterns book, as it's the one that led me to the article.
I don't know if it's because I used to be a Java guy or if I just made some assumptions. JUnit creates a new TestCase object for every single method when you run tests. That means that even global variables are reset for every single test method and are not shared.
This is not the case with NUnit. NUnit creates only one TestCase object, thus any global variables are shared. Tom, you're right in the fact that MVC creates the global variable for my routes, however, NUnit does not dump this and create a new one for each test like most other xUnit frameworks do.
I have placed the register routes code in the TestFixtureSetup method, and it works of course. I'm glad that I understand what's going on now.