I use this yeoman generator:
https://github.com/Swiip/generator-gulp-angular
It installs three testing applications: Jasmine, Karma , Protractor
According to this article (Should I be using Protractor or Karma for my end-to-end testing?), I should use: Karma for small tests of e.g. a single controller. Protactor if I want to test the whole app and simulate an user browsing through my app. According to this blog (http://andyshora.com/unit-testing-best-practices-angularjs.html) I would use Jasmine for unit testing and Karma for end-to-end integration tests.
I guess Jasmine is the language where tests are written and the other two execute the code, is that correct? Also if I never wrote a test which is more important to learn first/ to focus on?
Karma is a test-runner, so it runs your test.
Jasmine is the framework that let you write test
In my opinion in Angularjs you :
must unit-test services, because your business code is there.
should unit-test controller, because users actions are there.
may unit-test custom directives (if you plan to share that directive with others, it's a must)
Protractor is made for E2E testing (tests navigation like a real user).
It combines WebDriverJS with Jasmine and lets you write End-to-End tests (you simulate a real browser and taking real actions) with Jasmine syntax.
That kind of test is also really important in a web app.
You should not test everything, especially at the start of the project, those kinds of tests usually come with a high level of maintenance (i.e., when you change a screen you may have to change the test).
What I do is test the critical path and features.
I made a reading app, so in my case, it was login, sign up, payment, access book, and access reader.
Related
My app has a React front-end and ASP.NET core Web API back-end. I've built some unit tests (i.e. which stub out fetch()) with react-testing-library.
Now I want to do an integration test calling the real back-end API over HTTP. There are lots of standalone API testing tools I could do this, but then I'm still not testing the interface between the React components and the server.
Is there any reason I shouldn't simply write jest tests that don't stub out fetch(), and achieve a real end-to-end test? this seems quite obvious to me but I haven't seen any articles discussing it.
FWIW after getting the first few tests going it seems to be a pretty successful approach. I have been able to "almost" remote-control the UI (by which I mean it's not actually running in a browser, but it is using my React components) without having to learn or set up selenium.
The biggest headache was JSDOM's implementation of fetch (which in their defence probably wasn't meant to do this kind of thing). I ran into lots of problems with cookies and CORS so I used node-fetch instead and this gave me much more control over the HTTP requests I was generating.
I have an app that uses Vue.js as Frontend and Spring-boot as Backend.
I want to "unit test" (or integration test, whatever you wanna call it) my views, using browser and selenium, but mocking API calls (ajax requests).
Which tools are recommended to do that?
Selenium testing is called Integration or End-to-End (E2E) testing. Unit testing is not done with Selenium, it is usually done with one of the following tools: Jest, Karma, Jasmine, Mocha, or Chai. (some of these are "expectations libraries", some of these are "test runners", some are both)
Unit testing in Vue
Please check out the Vue Unit Testing guide. The community has strong preferences toward Jest currently, which means most of the tooling you can download for free is aimed toward people using Jest.
E2E testing in Vue
The modern, recommended tools for e2e testing a Vue app are Cypress or Nightwatch. I would start with those. Check out this article to get started.
If you still want to use Selenium, there is literally no difference between testing a normal web app and testing a Vue web app. This is because Selenium operates at the level of abstraction of the Browser, and doesn't care what network requests you make, what backend you use, or what frontend you use.
Which one do you need?
Well, both. This article will help guide you to choose between them, or to do both. There are tradeoffs to each. We recently ditched our e2e tests entirely in favor of writing more unit tests. It's been about 2 years, and it's going great
I am using Laravel 5.6 to write a API with no views, just endpoints.
I am very new to testing and my understanding is that Unit tests are from a programmers perspective and Feature tests are from a users perspective.
As i am only creating an API, would I be right to assume that i will only be writing Unit tests? and i am safe to remove the tests/Feature directory all together?
My tests will consist of things like
public function it_authenticate_a_user()
Sorry if its a dull question, i am only trying to learn.
Thanks
No, it's not a good idea to write only unit tests.
A true unit test verifies that a single class or function works as expected. However, it does NOT verify that the whole application works as expected - it's perfectly possible for the application to have 100% coverage from unit tests, but not actually work because the components don't quite fit together as expected. You should also write functional tests for your endpoints. The majority of your tests should be unit tests, but it's a good idea to make sure every API method is covered by functional tests too, just to make sure the pieces fit together.
Put it this way, at Google they advocate a model called the testing pyramid, which gives a typical ratio of 70% unit tests, 20% functional tests, and 10% high level acceptance tests. It should not be seen as rigid, and for an API I see little need for acceptance tests, but it gives some idea as to a healthy mix of tests.
An API is in some ways easier to test than a conventional web app since it's stateless and each method is relatively simple, but it's just as important it has functional test coverage. It's straightforward to test API routes in Laravel - just do the setup, make the request and check the response is correct and any changes have been made.
I have an interactive CLI app based on Highline gem. I can run it interactively for Cucumber tests using Aruba. But I can't using stubs and mocks, because Aruba starts my app as a child process. If I try to use Aruba::InProcess feature, it loses interactivity.
I have no idea any more. In what way can I testing such app?
What exactly do you want to stub and mock?
Cucumber is primarily used for integration testing, i.e. testing from end-user's point of view. End-users use the app through its interface, that's why cucumber does not provide easy ways of stubbing and mocking the app's internals and you should not do it either, at least not with cucumber.
Consider using fixtures for cucumber or unit testing with rspec.
If you want to stub out responses from 3rd parties, then you can use webmock gem to intercept requests and return fixtures as a response or fakefs to do the same for the filesystem.
Ok, I take that: Cucumber is not about stubs and mocks. And interactive CLI apps is, probably, the best example for it.
So, while you need interactivity, Cucumber through Aruba starts your app in a child process. And the only way for affect it, I find, is environment variables usage. For example, by setting variable with values 'production'/'development'/'test' I can change configuration of my app to using test DB instead of production etc.
So we've been running a daily build on our current project for a lot of months at this point. The smoke tests that goes along with that daily build isn't very complex, though - we run a few nUnit tests on our main class library (which, admittedly, doesn't offer great code coverage), and we make sure that things compile and build. The application in question is an ASP.NET site which consumes some business objects (which include LINQ-to-SQL).
Are there more complex smoke tests that we should be running, particularly on the ASP.NET sites? How would we develop a smoke test for an ASP.NET site, for that matter?
As well as unit testing, it can be good to launch the site to a staging server with some example data. As close to live-like as possible. Then use a HTTP traffic generating script to simulate user traffic and sessions. You can monitor debug logging, exceptions and other testing code on the back-end. You can also take performance measurements here.
Much like a more intense, iterative version of playing with it in the browser yourself.
You can do this by defining (or through inspection) your public resources and their inputs. The scripts can then try and cause validation problems, odd permutations of site flow and other things that test the entire context of the site in a live setting.
If testing is not complete ... from unit testing through to "does it play nice with real data and traffic" then you are ultimately going to be running around like a headless chicken fixing bugs later.
Smoke tests, by nature, should be superficial: Does it compile? Deploy? Does the welcome page load? Maybe load a test page which does a query against the database to see that this connection works, too. That's it.
You should not be doing smoke tests. Are you aware of the etymology of that term? A "smoke test", in electronics, is when you turn on the power and see if any smoke comes out.
You should be doing more comprehensive unit tests; enough to give you good code coverage. This is what you should do on every build. You should also try to do a deployment, and run some "installation verification tests".