Is there a way we can use QUnit to do E2E testing on Angular client?
I don't wish to mock the data from server but need to test real time response from service validating client services too.
Is there a work around, since what I've read that "angular-mock" has to be used for sending a request but it only mocks the server rather than sending an actual request to server.
I need to only code tests for service layer, therefore I'd like to make use of my QUnit tests (already written).
My last resort will be opting for Jasmine if this fails. :/
There is a wording confusion here. The question should be "how to write integration test with AngularJS".
What you are trying to do is to test two pieces of software together, which mean no unit test, but you are also not testing the whole angularJS app, so you are not doing e2e test either.
There is a karma-qunit-adapter that suggest your service layer could be test with QUnit, but as the name of the framework suggest it is to be used for unit testing purpose, so the solution you will achieve may be hacky. You will have to write your own generic adapters to test input/output requests.
Related
What is the correct way to write E2E tests using Cypress for my front-end React app and a 3rd-party API (server) that is not under my control?
Server not been under my control, means I can't seed the DB with test data to perform a specific test.
Although, I am aware of stubbing the responses I get back from the server, I feel that an E2E test should be as close as to real life (not stubbing or mocking things).
In my case, maybe stubbing is the only way to go. I don't know, as I'm new to testing.
Any help?
Beside stubbing there is another solution onboard of Cypress called 'Mocking'. In that case you feed the test the response you expect it to get. That is exactly
the solution which we are using in our frontend to really test the application. But beside those tests we have (what we call smoke-tests) which do a real E2E test. We choose to make the E2E more like a sanity test. For example:
Our mocked test does checks for complete forms including error handling. Our smoke-tests only tests 1 happy path and 1 sad path. If those two work, we dare to conclude that all mocked tests also work in real life.
I've just recently started to write tests for a web app I'm working on. And I've realised that I will have a lot of problems with my unit tests if a data, with which server responds, will change. Because all response data is mocked in app client-side tests, the tests should pass.
According TDD I should write tests first and only after that change the code.
Well, if I could quickly change all mocked data in my tests according to new data format, then it would be fine (I could see where tests fails). But what if I cannot do it quickly, what if there are many places where I need to do that and I just don't know where to look at?
So here is my question: is this problem comes down to the fact that I need to write tests in such a way as to be able easily change (or check) mocked data format in all of my tests? Or there are other solutions on that?
I want to do a smoke test in order to test the connection between my web app and the server itself. Does Someone know how to do it? In addition I want to do an acceptance tests to test my whole application. Which tool do you recommend?
My technology stack is: backbone and require.js and jquery mobile and jasmine for BDD test.
Regards
When doing BDD you should always mock the collaborators. The tests should run quickly and not depend on any external resources such as servers, APIs, databases etc.
The way you would want to make in f.e. Jasmine is to declare a spy that pretends to be the server. You then move on to defining what would be the response of the spy in a particular scenario or example.
This is the best aproach if you want your application to be environment undependent. Which is very needed when running Jenkins jobs - building a whole infrastructure around the job would be hard to reproduce.
Make spy/mock objects that represent the server and in your specs define how the external sources behave - this way you can focus on what behavior your application delivers under specified circumstances.
This isn't a complete answer, but one tool we've been using for our very similar stack is mockJSON. It's a jQuery plugin that does a nice job both:
intercepting calls to a URL and instead sending back mock data and
making it easy to generate random mock data based on templates.
The best part is that it's entirely client side, so you don't need to set up anything external to get decent tests. It won't test the actual network connection to your server, but it can do a very good job validating that type of data your server would be kicking back. FWIW, we use Mocha as our test framework and haven't had any trouble getting this to integrate with our BDD work.
The original mockJSON repo is still pretty good, though it hasn't been updated in a little while. My colleagues and I have been trying to keep it going with patches and features in my own fork.
I found a blog post where the author explain how to use capybara, cucumber and selenium outside a rails application and therefore can be use to test a javascript app. Here are the link: http://testerstories.com/?p=48
We've just started developing a web app with AngularJS and we're having some problems with testing it properly so we could use some advice.
Generally, there are the following components to test:
Web API
Angular Controllers
Angular routing
HTML rendering and Angular binding of Controllers to the HTML elements
How does one test all of this with minimal effort and no, if possible, overlap?
For any database-centric application, complete integration testing (i.e. with a live server, connected to a database loaded with data) would be particularly messy because there would have to be a process that generates sufficient data for all tests and resets the DB and tests would have to be careful not to modify each other's data. (if I'm missing something here please let me know)
Given the above point, I'm assuming it is best to sever the link between server and client and run the Angular tests using mock data only.
Also, I'm assuming that if E2E testing takes care of all possible scenarios, unit testing controllers is redundant as their values are bound to the model (and would thus be testing all of 2, 3 and 4 above). Unit testing would only be helpful in very complex controllers or to test services and directives.
However, we could not find any information on how to mock stuff with $httpBackend on a per-test basis like you would do in unit tests, using expect*(). Angular docs seem to suggest using when*() plus the occasional passthrough() when necessary.
But, this poses the aforementioned problem of creating test data for all scenarios and you'd probably need to reset the in-memory DB before each test to be sure the tests are not affected. Also, you're losing the safety of using $httpBackEnd.expect*() which checks that there are no missing or redundant calls to the server - This would suggest to me that it would also require unit testing controllers to check this.
Can someone provide a detailed testing strategy for AngularJS apps that addresses the testing of the 4 components above as well as the concerns written above?
Not sure - since your angular app is theoretically decoupled from your backend, there's no particular reason that angular tests and backend tests need to be commingled. I would test them separately, with each test suite assuming that the other component works fine. (So when testing angular, you assume that the server will work as expected.)
Unit tests - they provide more depth than E2E tests. It's easier to verify specific conditions the code will face. It's also easy to mock out all dependencies as necessary and test just the component the unit tests is interested in. Unit tests don't concern themselves with how the UI works, or that the right data is bound correctly, but rather than the business logic of the app is correct.
(and 4) E2E tests - less granularity, focusing on making sure the UI looks as expected from an end user perspective. You are right that it's messy to test against a live database (although some people enjoy the safety provided by a full end-to-end integration test), and so you should use $httpBackend to mock out the server.
Refer this https://www.sitepoint.com/unit-and-e2e-testing-in-angularjs/.
If your service/factory uses the http service to call a remote API you can return fake data from it for unit testing.If you are starting a new Angular project consider using Protractor for E2E tests.
I'm writing up unit tests for a app but I'm having difficulty keeping track of what scenarios I've tested for in each method.
I'm currently using qunit and creating a testing directory for each object that I'm unit testing and a single file for each method I'm testing but how do you get a good overview of all your tests in an easy to digest form?
Ideally I'd like to have something
which could take my unit tests and add the test description next to the function which it relates to in the code itself so when in the code I can see the tests I've got for the method straight away
have some sort of easy to read overview of all my tests
Does anyone have any recommendations of tools or practices which may help out with this problem?
The projects I've worked on have all been Server+Client projects, where we had a suite of unit tests for our server side code, and wanted to integrate our client side unit tests into that process.
In that case, I have written a "Unit Test" in my server side code that opened up each QUnit test in a browser, then scraped the DOM for success/failure entries, and called Assert(false, text_scraped_from_dom). Then all of my qUint tests were run as part of my CI build and showed up as failing tests there.
I have done this for Java with httpunit, and for .NET with watin.