How to use testcafe for client side performance testing? - testing

I want to use testcafe for client side performace testing.Is it possible or is their any alternate option is available for client side performance testing?

TestCafe is intended for the e2e testing, not for the load/performance testing.
However, you can use approaches described in this thread:
Testcafe concurrent load test performance.

Related

Using OWASP ZAP Proxy for existing suite of Selenium tests

We have a suite of automated regression tests driven using Selenium for an Angular app with a .NET Core WEB API backend.
The intention is to include some automated security testing as part of our overnight build/test run.
From reading so far it looks like running ZAP as an intercepting proxy between Selenium and our web application is the way to go (see 'Proxy Regression/Unit Tests' in https://www.zaproxy.org/docs/api/#exploring-the-app) but I'm struggling to find clear documentation/examples.
What is the simplest way to achieve this using OWASP ZAP, and are there any definitive articles/examples available?
Start with the packaged full scan: https://www.zaproxy.org/docs/docker/full-scan/
Set the port and then proxy your selenium tests through ZAP. Use the -D parameter to pause ZAP until your tests have finished. For more ZAP automation options see https://www.zaproxy.org/docs/automate/

Performance testing tool vs performance testing tool Plugin integration with other tools

What is the difference between
Using the performance testing tool directly(Jmeter ,..)
Integrate the performance testing tool with selenium using plugin(Jmeter ,..).
Whether I can achieve all the functionalities in both the ways.
If used as a plugin will there be any limitations?
Thanks.
Performance testing tool acts on HTTP protocol level, basically pretty much the same as browser does, however in particular JMeter:
JMeter is not a browser, it works at protocol level. As far as web-services and remote services are concerned, JMeter looks like a browser (or rather, multiple browsers); however JMeter does not perform all the actions supported by browsers. In particular, JMeter does not execute the Javascript found in HTML pages. Nor does it render the HTML pages as a browser does (it's possible to view the response as HTML etc., but the timings are not included in any samples, and only one sample in one thread is ever displayed at a time).
therefore you can only test backend performance using JMeter however you will not get client-side performance metrics
Protocol-based tests have much less footprint in terms of resources (CPU, RAM, etc.) so you can simulate thousands of virtual users from a mid-range modern laptop.
Selenium is a browser automation framework, it operates real browsers so:
you have client-side performance metrics (including ability to query Window.Performance metrics)
and you don't have HTTP-protocol related metrics (connect time, latency, concurrency, throughput, etc.)
Browser-based tests have huge footprint in terms of resources as browsers are very resource intensive, for example Firefox 74 requires 1 CPU core and 2 GB of RAM per browser instance so you can kick off only several browsers on a mid-range modern laptop
Depending on your requirements you might want to either test the backend using JMeter or the frontend using Selenium or create the main load using JMeter and use 1-2 real browsers to test client-side performance.
If you're looking for a way of integrating JMeter with Selenium take a look at WebDriver Sampler (it's a JMeter Plugin which can be installed using JMeter Plugins Manager)

Client - server integration testing: mock or not?

I'm working on project with two applications: android app (client) and rest service (server). My android app consumes my rest service.
Both applications are tested separately to ensure they're doing their business as expected.
During server tests I prepare requests and check server responses.
During client tests I set up a simple http mock server and test client's requests against different mocked responses.
Now, this technique works pretty well. It gives me a flexibility I like. I can use different test frameworks and continuous integration environments. But there is one weak point. In both (client and server) test cases I specify the same api. I assume that e.g.
GET /foo-list.json
will return HTTP 200 with json
[{
id: 1,
name: foo1,
}, {
id: 2,
name: foo2
}]
So I repeat myself. If I change a response format my client tests won't fail.
My question is about good practices in testing this kind of scenario. How to make true integration tests without sacrificing flexibility of independent tests. Should I test client with mocked server or with a real instance of my rest service?
Please share your professional experience.
In your scenario you should continue to write unit tests to test individual classes, and integration tests to test the inter-operation between multiple application layers (e.g. business and database layers).
You ask:
"How to make true integration tests without sacrificing flexibility of independent tests"
All of your code should should use abstractions, so that you can use dependency injection to unit test classes in complete isolation using mock dependencies. The use of mocks will ensure that these tests will remain independent i.e. not coupled to any other classes. Hence taking this approach, the integration tests, which would use your final concrete classes, would not affect the unit tests which use the mocked classes.
Also:
"Should I test client with mocked server or with a real instance of my rest service?"
In addition to unit and integration tests you should also perform client-server integration testing; I use automated acceptance testing for doing this. Using a test framework such as Cucumber (also check out calabash-android, which is written specifically to test mobile applications) you can write tests which would test specific features and scenarios which would interact with both the client (your Android application) and server (your RESTful service). These client-server integration tests would start-up and stop concrete instances of the client and server.
Mocks are for unit testing. Your description of the tests with the mocks describes exactly that. You test the client and server as separate units.
Integration testing tests if the units work well together. Since the interface is a REST interface, mocking makes no sense then, you have to test the real thing over HTTP.
See also What is the difference between integration and unit tests?
If your service is based in Java, I'd strongly recommend looking into the Spock framework, for mocking any sort of calls that might be coming from the client. Since Spock is just an extension of jUnit, you might also be able to use it for Android (though, to be fair I've never done Android development)
I'd say you want to do two things. Integration testing and Unit testing. Integration testing would attempt to bring up the android application and cause it to make service calls, ensuring the contexts interact with each other kindly.
However, in your regular commits, I'd suggest unit testing that mocks away everything but the class under test. Spock makes this pretty easy to do, and since it's built on top of jUnit all it takes a jar.
There is no reason you can't run automated end to end tests with a real service instance. You can run a real service instance on the same test machine you are using to run the unit tests, perhaps in the same container. You can set up configuration to use a different URL for the server instance for running automated end to end testing.
Why would you want to do the extra work of creating the mock service if you can run them against the real service?
I would only create a mock service, if the service was an external service over which I had no control!

Demandware site testing

We are using Demandware for our eCommerce site so they are giving sandboxes for development and testing.
I am automating the site for regression testing. But if I run automation scripts on Testing sandbox, sometimes it is taking longer time to load the page as a result test fails.
So what is the best way to do automation testing on Demandware related websites ?
Is it possible to deploy site to Cloud ?
Is is possible to increase the performance of testing related sandbox ? So tests will not fail?
Can you please suggest your thoughts?
Use development instance for these tests, as it is close to production in terms that it uses Akamai CDN, so the loading of pages will be relatively faster.
If sandboxes/development instances are performing slow, it may be good idea to look in Pipeline profiler in Demandware Business Manager to get insight as to where the performance bottleneck is lying.

what's nodeJS suit for? use nodeJS to do the automate web UI testing?

everyone
do you think nodeJS suit for the web UI automate testing?
I don't think so.
first, nodeJS base on V8 engine, so how to test the issue on IE6-8?also how about other
no web-kit based browser?
second, what's nodeJS suit for?
What are you talking about? NodeJS is designed for writing SERVERS, not clients. It has nothing to do with browsers.
Imho NodeJS is the best choice for writing high traffic web servers. Also together with websockets it is also very good choice. And it is the future of web designing since the unification of language used in client's side and server's side.
You can use nodeJS to connect to Selenium and do automated UI tests, Soda (https://github.com/testingbot/soda) supports this.
If you want to use a node.js based headless browser to automate UI tests, check out zombie.js. If you want to create a UI test suite that runs against different browsers, I'd highly recommend selenium.