I have a quiz tool and I want to see how can I test this for 100 simultaneous users. This quiz tool have JS for its front-end and the JS is calling RESTful API.
I have some tests running on for trivial stuffs like login in Nightwatch.js for my web application but the question is how it can guarantee a number of simultaneous users?
As far as I'm aware none of the load testing tools will execute JavaScript, so the options are in:
If you need to simulate load directly on front-end and check rendering speed as well as REST backend performance you should go for browser-based testing using i..e Selenium Grid
If you think that simulating the load on REST backend will be enough you can simulate the load using i.e. SoapUI or Apache JMeter.
Personally I would combine above approaches i.e. created the main load with SoapUI or Apache JMeter and checked JS frontend client-side performance either manually using something like YSlow or in automated manner using Selenium depending on if there is an adhoc activity or something which will be executed on the regular basis.
Related
I need to automate my web application functionality using rest assured.
Means there are no endpoints to verify the functionality of login module on the homepage and I need to automate same login Page functionality using Rest Assured.
Please, anyone, tell me to know the solution of my this query.
Rest-Assured is just a REST testing tool, you can't use it to perform UI functional testing.
You should use one of the tools dedicated to that, like Selenium.
The best way to go is to split your testing in two separate projects.
Backend functional testing with Rest-Assured (Making REST calls).
Frontend functional testing with Selenium (Using Selenium).
I have written a code in html for signup a website and saved into my local machine with .html extension.
In browser it showing as file:///C:/Users/xxxxx/Desktop/hello.html
can I able to do loadtest for this url using jmeter?
No (unless you are testing the speed of your file system).
The whole idea of load testing is:
Have your web site deployed onto environment close to real (the one, you'r going to have in production) so you need to consider some form of a web server software (and hardware) and deploy your website there
Mimic the load coming from real users as close as possible. It means that your JMeter test should look like exactly a real browser from the web server's perspective.
This way you should be able to confirm whether your web site is capable of handling anticipated load (or determine its boundaries so see where/when it fails)
More information:
Building a Web Test Plan
Logging in to a web-site
Jmeter measure the speed between to requests, and generally the backend speed. If you want to test your file on directly on your disk without any http ou application server , Jmeter is not the good tool. The loading time page speed can be measured by the Browser Developer tools (F12 key browser) .
The application is using Minitest on Rails 4 with Capybara.
I'd like to write an integration or feature test that stubs a websocket connection (the application uses Faye as a client) to return a specific message (like I'm used to doing with Webmock).
Is this possible? If so, can you provide an example? My research has not turned up any examples.
Your research hasn't shown up any examples because it's not really what you're supposed to be doing in feature tests. Feature tests are supposed to be end-to-end black box tests where you configure the data as required for the app to generate the desired results and then all interaction is done via the browser (no mocking/stubbing which technically alter your apps code). Additionally when connections between the browser and a 3rd party service are involved there is nowhere in your app where you can mock it.
It may be possible to stub a websocket connection from the browser with a programmable proxy like puffing-billy, however it's generally cleaner to produce a small fake version of the 3rd party service for testing purposes (sinatra app, etc) and point the browser at that rather than the original service when you need to craft custom responses. Additionally, there are a lot of fakes already out there, depending on what service you are using (fake-stripe, fake-s3, etc), which may provide the functionality you're looking for.
I have an app with a Rails backend and a React frontend. I am deploying it in Docker containers: one for the app, one for postgres, and one as a data volume container. I have it working, but the app image file is huge (3Gb!) and takes a long time to build.
I'd love a way to split it up. The React app needs a bunch of Node packages, but only for development; once it's all webpack-ed the React app is essentially static files. And the Rails app doesn't need Node at all.
I don't need all the development-time tooling in the production image, but as it is, I feel like I need to have it all in the same codebase so I can (eventually) set up a CI/CD environment that can build the app and run all the tests. Is there a way to do this such that I'd have a container for the React/Node app and a container for Rails, and connect them at runtime?
I think that you may have found the answer to your question already - split the code bases.
We all have some kind of knee-jerk reflex to want to keep everything in a project in the same repo. It feels safe. Dealing with separate repos seems quite scary, but so does not moshing CSS and JS into HTML for most beginners.
I feel like I need to have it all in the same codebase so I can
(eventually) set up a CI/CD environment that can build the app and run
all the tests
Well that would be nice - however testing javascript through Ruby or automated browsers is painfully slow. You end up with a "fast" suite of unit tests and a slow "suite" of integration tests that take 15+ minutes.
So whats the alternative?
Your API and your SPA application (angular) actually do very different things.
The API takes HTTP requests and poops out JSON. It runs on a Ruby on Rails server and talks with a database and even other API's.
You would do integration tests of you API by sending HTTP requests and testing the response.
Your API should not really care if the request comes from a Fuzzle widget and renders a happy face or not. Its not the API's job.
RSpec.describe 'Pets API' do
let!(:pet) { create(:pet) }
let(:json) { JSON.parse(response.body) }
describe 'GET /pets' do
get '/pets'
expect(json["name"]).to eq pet.name
end
end
The SPA server basically just needs to serve static HTML and just enough javascript to get stuff rolling.
A docker container seems almost overkill here - you just want a nginx server behind a reverse proxy or a load balancer as you're only serving up one thing.
You should have tests written in javascript that either mock out the API server or talk to a fake API server. If you really have to you could automate a browser and let it talk to test version of the API.
Your SPA will most likely have its own JS based toolkit and build process, and most importantly - its own test suite.
Of course this highly opinionated, but think about it - both projects will benefit from having their own infrastructure and a clear focus. Especially the API part which can end up really strange if you start building it around a user interface.
You can take a look to my rails react project at github.com/yovasx2/aquacontrol
Don't forget to start and fork it
I have a website that I want to test using Selenium WebDriver (version 2.28), and to integrate it with my CI (Maven and Hudson).
The thing is that in order to properly test the front-end, I need to access the server (for the actual HTML and for REST resources). The test will not be fully encapsulated if I access the actual server that I build and deploy during the build process, since the data might be different each time (based on the data that resides in the DB of the built environment at the time of the build).
Therefore it seems to me that I have to mock the server access.
I just don't find a support for this in Selenium, and I can't quite think of the best way to do that without a Selenium support.
I can create mocks to all of my resources (HTML and REST) in the actual server, on different URLs, and access those in my tests instead of the production-level ones (with some kind of a flag to indicate that I should access mock resources instead of real ones). But that's not really mocking...
For reference, I saw that in the Sahi test framework there's a feature of addMock(url, class_function) - in which when Sahi runs into the specified URL, it will call the specified class and function instead of access the URL, whereas the class and function should provide the resource instead of the URL providing the resource.
I'm looking for something similar in Selenium (though perhaps it's not possible, since Sahi functions as a proxy).
Many thanks in advance,
Daniel