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.
Related
I am using Inertia and would like to run some tests to check whether the response contains a certain string.
->assertInertia(
fn (AssertableInertia $page) => $page->component('UsersPage')->has('profile')->dd('profile.0.buttons')
);
so the above works and i can dump the profile.0.buttons and see the string i want to check for, but how do i automatically test that this string exists? normal unit tests, i'd use assertSee. whereContains also doesn't work.
I think that Inertia page about testing has done a great job in summing the testing option for Laravel/Inertia.
Endpoint tests (assertInertia) are feature tests, and you can use them to check if a controller is sending the right components and data to Inertia.
Your question is going more in the direction of "Client-side unit tests" e.g. Jest, where you can send some data to React/Vue component and see how that data has been rendered.
There are "End-to-end tests": Cypress is great but lacks nice integration with setting up Laravel enviroment and seeders in test.
That leave us with Laravel Dusk. I love this tool because it give us best of both worlds (backend and frontend).
You can set up your test with seeders or Model factories, and in the same test you can fire up virtual browser and see how Inertia rendered page. Best thing is that you can use helpers for typing and clicking so you can realy test your app and how it behaves.
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.
I just completed writing a detailed rspec capybara integration and unit tests for Rails app, which includes mocking Omniauth (twitter) login, filling in forms, data validations, etc. However, I am wondering whether there is a need to write a separate controller or functional test.
Would appreciate your input and any links to further readings etc.
I'll play devil's advocate here, since I know I'm probably in the minority with this opinion: I actually prefer to do exceedingly thorough controller testing. A few reasons:
1) I find it easier to systematically test every path and outcome at the controller level than at the integration test level. My integration tests are primarily just happy-paths, and some of the more common error paths.
2) A lot of potential security issues occur at the controller level. Thorough testing helps me ensure that nothing malicious can get through to my model logic.
3) This is subjective, but it really forces me to think about some of the long-tail paths that my application might go through. What if someone tries to for an invalid password reset token into the URL? Controller testing ensures that I consider all options.
4) Unlike integration tests, they're fairly straight-forward to test. Each action is just a ruby method!
Personally, I think if your request (integration) spec is exercising all code paths you're covered. Ryan Bates has a great Railscast about how he tests here: http://railscasts.com/episodes/275-how-i-test?autoplay=true and about 5:05 in he says a similar thing. Like you I like to write integration tests rather than controller specs. Most of the time controllers simply front CRUD type operations anyway (especially if you're careful about keeping domain logic out of the controller), so all you're testing is the scaffolding.
We have a isolated test automation team responsible for automating only watir+cucumber functional test cases. Their code base is not attached with the rails app that other developers are working on, but kept separate. We have automated several test cases so far, and now what problem we have is, some (watir/cucumber specs)test cases require some data to be preexist into db, so it(testcase) should focus only on the problem stmt, and not creating any data-require itself.
Example, say if it has to check whether rating is working for a post, it requires a post object should preexist and it just checks rating. And not creating 1st post object and then checking its rating.
What are the best approaches here? Like we have fixtures and factory-girl for rails unit testing, what is there for cucumber specs? Or Shall we make use of features only here? These testers may not have idea of all models that exist, do they be aware of them so to make use of fixtures by calling Rails-Model interface.
My idea was, when we write feature file, it should not point or talk about any Model which looks meta stuff. Watir/specs test cases should only be aware of "Web-application"/browser only as the interface to talk/deal with the application. They should not know any other interface(fixture/Models). Hence they should create their own data on their own, by making use of the single interface they know.
Again, what I want to know that, is there any ruby lib/code, given table names, column names, and values(all most like fixtures yml), along with db parameters. It will simply insert them into db, without context of rails environment. And so testers those are having their environment isolated from rails web developers would able to work on their own. Rails fixtures, or factory girls seem to be well coupled with rails. Or am I incorrect?
Like Chirantan said you could use Factory girl with cucumber.
As require your factories in test unit or RSpec, you can do the same in the cucumber's env.rb file or any custom config file.
http://robots.thoughtbot.com/post/284805810/gimme-three-steps
http://www.claytonlz.com/2010/03/zero-to-tested-with-cucumber-and-factory-girl/
http://www.andhapp.com/blog/2009/11/07/using-factory_girl-with-cucumber/
When using cucumber, the Given statement sets the test situation up:
Given I have a basic user with a password
and the When statement triggers the test:
When the user logs in
and the Then statement checks the test results
Then they see the basic menu
The data gets loaded in the Given statement.
I feel like I'm stuck in this political/religious battle. From the research I've done I've found that many people believe very strongly that UI testing is silly to do via unit testing and is something much better done by an actual person. I agree.
However it seems the higher-ups have told me to unit test the UI. (Which is already strange since they had previously told me I only had to write a test plan and not actual test). In all sincerity I'm not very familiar with unit testing. I'm trying to use MOQ but all the tutorials I find for it use repositories and not services and I'm structuring my web application around services.
As an example here is (a part of) a service:
public class ProductService : Service<Product, EntitiesDbContext>
{
...
public Product GetProduct(int id)
{
return All().FirstOrDefault(p => p.ProductId == id);
}
...
}
My assumption is that I need to create let's say, a new Product using Moq, and then someone validate the hard-coded input using my model. I'm not sure how to do this.
Testing the UI is the bulk of my work as the website relies heavily on user input via forms. Again I find it quite silly to test with unit testing since my models are very strict and only allow certain inputs.
To my question:
How would I go about testing form input using MOQ or possibly another testing framework?
I've heard that there are programs out there that can track your actions and then replicate them, but I've been unsuccessful in finding them and I also believe that such a technology would cost money.
Try Selenium or Watin for UI testing.
Visual Studio 2010 Ultimate has something called Coded UI test. Basically, you record your actions in Internet Explorer, which translate to C# code where you add assertions, and then you replay the actions in different browsers.
However, it is very difficult to test against a database backed web application, since you can hardly figure out which is the newly added row. To simplify matters, you might want to set up a sample database which will be reset to its initial state before running your test suite in sequence.
Take a look at the various TechEd videos on how to use Coded UI Test. E.g. http://www.youtube.com/watch?v=rZ8Q5EJ2bQM
Are you testing the Actions for your UI or are you testing Actual UI.
If you are testing the Actions and what data they are sending to the view then doing unit tests using something like NUnit, xUnit, etc and using a moq framework like MOQ or Rhino Mocks would be the right thing to do.
if you are testing the Actual UI(the HTML returned by the web server) then using an automated testing framework like Selenium would be the right tool
You can also try Ivonna (http://ivonna.biz) for MVC testing -- doesn't test your client side, but lets you test your Asp.Net server side code.
But first of all you should ask yourself (or your management) a question: what do I want to test? Client/server side validation? Your Service? Action Method?
There is a lot of opposition by developers to automate testing of the UI. What I did years ago was use "Selenium Core" This allowed me to fix do the testing in Firefox, then save out as C# , and then have a blend of C# and Html files in which I could have it do the following.
Forgot Password -- Automation random usernames from database would be entered and then encrypted passwords were emailed to various gmail accounts I set up and I had C# API to login to gmail and retrieve new reset password, then redirect and have application enter new password , and I could put this on a CI Server Hudson and automate this testing all day long, and logging of success and errors etc...
New Registration... similar to #1
So for your UI testing, lets call that Functional or UAT testing ...
Then for true Unit Testing, this is for NUnit / Xunit, MSTest etc... , and then MOQ etc... can assist.
Integration testing is truly testing of the entire application with connected systems... like a file system or WCF or Database , not being "mocked"
They all have their pros and cons and none of it is perfect, but most people end up saying Unit Testing is most bang for the buck.