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
Related
I have recently started working with Cypress and looking forward how to test GraphQL end points.
Cypress is used to perform e2e tests, so it makes no sense to use Cypress if you need to test only endpoints. There are plenty ways of how to test GraphQL api, just try to google more and pick one.
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 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.
I would like to do integration testing on my Web API Controllers.
When the integration test starts the whole request/response pipeline of the Web API should be processed so its a real integration test.
I have read some blogs about non-InMemory-tests or InMemory tests. I need to know what is the difference and what of those approaches matches my above criteria?
I would really be glad about some explanations from people who really dealt with integration testing on Web API for self-hosting or IIS hosting (if there is a difference in testing...)
Not sure what you mean by non-in-memory testing but with integration testing involving an in-memory hosted web API, the requests are sent directly to the HttpServer, which is basically the first component to run in ASP.NET Web API pipeline. This means, the requests do not hit the network stack. So, you don't need to worry about running on specific ports, etc and also if you write good amount of tests, the time it takes to run all your tests will not be too big, since you deal with in-memory and not network. You should get comparable running times as a typical unit test. Look at this excellent post from Kiran for more details on in-memory testing. In-memory testing will exercise all the components you setup to run in the pipeline but one thing to watch out for is formatters. If you send ObjectContent in the request, there is no need to run media-formatters, since the request is already in deserialized format and hence media formatting does not happen.
If you want to get more closer and willing to take a hit on the running time, you can write your tests using a self-host. Is that what you mean by non-in-memory testing? As an example, you can use OWIN self-hosting. You can use Katana hosting APIs and host your web API and hit it with your requests. Of course, this will use the real HttpListener and the requests do traverse the network stack although it is all happening in the same machine. The tests will be comparatively slower but you get much closer to your prod runs probably.
I personally have not seen anyone using web-hosting and doing lots of integration testing. It is technically possible to fire off your requests using HttpClient and inspect the response and assert stuff but you will not have lot of control over arranging your tests programatically.
My choice is to mix and match, that is, use in-memory tests as much as possible and use Katana-based host only for those specific cases I need to really hit the network.
I want to load test the web application that we're working on? Can you name some automated load testing tool for a website developed on asp.net mvc3? I would like to develop it for concurrent 100 users, 200 users and so on. We want to test it with many users and test the load that creates on the application and server.
BTW, we're also running profiler at the same time to find the application bottlenecks so that we can find code that is slow that we can improve.
There are a number of different options; they vary in all kinds of exciting ways.
I use the open source Apache JMeter for this kind of testing - it's not hugely user friendly, but is very powerful once you get used to it, and the lack of licensing restrictions means you can use it in all sorts of configurations.
Some of our projects have glued JMeter into the continuous integration cycle, running performance tests on nightly builds. Some projects need to scale to huge numbers of users, and we use JMeter in the cloud (there are some service providers who can do this too).
it works nicely with Asp.Net MVC apps.
We are currently load testing our MVC application and the external company uses a product called LoadRunner.
However, depending on how intricate your testing is you could use the WebClient class as a base to run your own volume tests.
Web Performance Load Tester works very well with .NET apps. We test a lot of them (disclaimer: I work for Web Performance and am closely involved with the product).
We have integrated with Fiddler load testing tool called StresStimulus