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.
Related
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'm trying to build a simulator that simulates hundreds of users on a web application.
I'm usually using Microsoft Load Simulator and WebTests.
If the webpage has some complexity I'm using WebTest plugins to adjust it correctly.
Now, I have a web page that does tons of ajax requests per url I visit, the ajax requests are based on complex calculations done in the browser.
If I'll just browse to the url and record all the traffic, even after I'll make some dynamic parameters I still won't be able to simulate it correctly since there may be different requests that could be sent based on the server previous responses.
If I'll build a webtest that simulates it correctly it will require a lot of webtest plugins and will be impossible to maintaince since the site will probably change each few weeks.
I thought about using selenium but if I'll use it I will need far too much hardware resources to run hundreds of users.
I came up with the idea of using a headless browser such as PhantomJs, SimpleBrowser, HtmlUnit and etc.
Both SimpleBrowser and HtmlUnit does not support executing javascript/AJAX which makes them useless for me.
I tried using PhantomJs but I had a problem with running multiple users in parallel since the localStorage is the same for all so it keeps the same session for all so I can't simulate different users in parallel.
Does anyone had any experience with loadtesting complex ajax web applications?
I will Love you for eternity if you would help me with this issue.
P.S
I'm usually coding in C# but I'm open for new languages\technologies.
Using Selenium for performance testing is not logical. I recommend you to use Locust for real performance testing. For getting and using a dynamic data you can check the this answer. You need to write simple Python script for simulating users.
I am investigating www.loadbooster.com that can import a Selenium script and run headless borwoser with PhantomJS to run the script as a load test.
It is still work in progress for me, so I cant comment on how good it is, but you could investigate it.
Our requirements for a real-time web framework include:
lightweight framework
scala support on server side
flexible on communication mechanism : may be Ajax, Server Sent Event or WebSocket.
relatively little changes required to client html.
E.g. using the WebSockets js library is fine
introducing significant compile time/server side page processing is not. E.g. Play routing annotations are not acceptable
must have working examples for both:
web clients
server to server communications
fully functional build. Preferably sbt, but maven maybe acceptable
I have evaluated the following frameworks: and each one of them has one or more drawbacks that make usage within our application less than desirable.
Play: somewhat heavy, but more importantly it introduces custom annotations/processing into the html page. We need VANILLA html pages.
Spray: closer to the mark. But although I found a number of example applications, the actor-based communication is not working in those examples. The SimpleServer example has a built-in "cases" counter (from SimpleClient) that do not work as given: they could certainly be made to work .. eventually..
atmosphere: lacking examples
jetty, netty: lacked fully functional examples buildable within sbt or maven
socko : The markdown essentially stipulates using eclipse/scala-IDE for running tests/doing development. That is a non-starter for us (IJ shop). It was unclear how to run examples and/or start their servers from sbt / command line.
I ended up writing a fair amount of custom code wrapped around Netty. After it is in better shape I may drop it on GitHub.
http://xitrum-framework.github.io/ is actively developed and contains SocksJs support. It is rather lightweight, you can directly annotate routes on actors and they become exposed on the web.
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.
Are there any best practices in writing unit tests when 90% of the time I'm building the Oauth connecting class, I need to actually be logging into the remote service?
I am building a rubygem that logs in to Twitter/Google/MySpace, etc., and the hardest part is making sure I have the settings right for that particular provider, and I would like to write tests for that.
Is there a recommended way to do that? If I did mocks or stubs, I'd still have to spend that 90% of the time figuring out how to use the service, and would end up writing tests after the fact instead of before...
On a related note, if I created test API keys for each Oauth provider, and I just used it for the gem for testing purposes, is there any issue in leaving the api key and secret in plain view in the tests? So other people could test it out more realistically too.
nothing wrong with hitting live services in your integration tests.
you should stub out the oauth part completely in your unit tests though
If you're planning on open sourcing the code you're writing, leaving API keys in the code might not be a good idea as you might hit API usage limits or rate limiting when the gem becomes popular and people run the tests frequently which will lead to unexpected test failures.