Our main frontend (known internally as dunelm-web) runs 460+ browser tests in parallel AWS Lambda functions. Each test case is a separate Lambda invocation, and we trigger all of them at the same time.
We are very happy with our implementation; we have seen great benefits in terms of pipeline speed and reliability, and we are extremely excited to share our findings with the wider industry.
In our previous post, we took a look at and implemented our very first simple test to verify that the entered name is displayed correctly on the page. In that post, we learned how to install and configure TestCafe and how to run our e2e tests. Today we’ll dig a little deeper into the framework’s capabilities. To optimize the effort and reduce the execution time of our tests, we’ll run our tests in parallel in two different browsers! Ready? Let’s start!
If you think, that WebdriverIO is the only framework to test web apps, think again. When you start with a new testing framework for the web, it usually requires WebDriver or Selenium as a dependency, in some cases you also need to install (or at least update) JDK. Once you start the framework implementation, you might also decide to integrate tools such as test reporting tools and cloud support, into it, so you start to research which package is best for your needs. If you want to try out something new and you don’t want to search exhaustively for 3rd party packages to integrate, TestCafe might be your best friend.
I know it has been too long since my last blog, but I have started writing again and this time I have come up with a technical blog.
I tried my hands on an end-to-end testing automation tool named ‘Testcafe’ (new to me) which is similar to Cyperss.io, a well-known tool used in UI automation. And I found that there are many reasons for which I vote Testcafe as a user-friendly automation tool.
As its name suggests, end-to-end testing involves testing the flow of an application from beginning to end. Typically, we’re testing the numerous ways a user might interact with an application/website in order to ascertain that an application will work as expected.
A tester walks into a TestCafé and orders a Mockito. Instead of reading bad jokes, wouldn’t you rather extract the data of TestCafé tests and store them in an InfluxDB? Do you want to visualize those tests on a Grafana dashboard? Or are you looking for inspiration to create your own solution? Then you’ve come to the right place!
Usually, in an automation test project, there will be at least one test suite which has one or more test groups. Under each test group, there will be one or more test cases. Features that help organize these test cases are essential for test automation projects. Many junior level automation testers do not have the high level picture of what a project should looks like, which make it difficult for them to organize test cases in code repository.
Recently I decided I wanted to learn more about end-to-end testing. In the interest of getting hands-on quickly, I chose to add TestCafe to one of my pre-existing projects so I had a featureful app ready to be tested. This project was already using Jest for unit and integration tests. This redundancy was intentional, as I wanted to write TestCafe tests that cover the same cases as my Jest tests for learning purposes.
A couple of months ago, I began my journey of implementing testing into my projects and working with the automation framework TestCafe, and wrote an introductory blog that you can check out here. Today, I’m going to expand on what I discussed then and show y’all 5 important actions any TestCafe user should know.
While you can run TestCafe tests on any machine that has Node.js installed, it is more convenient to run them in a Docker container. This has the advantage when running the tests you don’t need to think about any dependencies, Node.js version etc. It also makes tests less flaky, because the environment the tests run in is always the same, either locally or in the CI environment. This is even more important when using TestCafe for visual regression testing, because then the screenshots will look the same wherever you run the tests.
We successfully hosted a webinar in collaboration with DevExpress on 2nd December 2020. The host, Mudit Singh- Director of Product & Growth at LambdaTest, got together with Paul Usher from DevExpress. Paul is the Technical Evangelist at DevExpress, the team responsible for creating TestCafe. We had a full-house during the webinar, and people have been reaching out to us for a more detailed blog around the webinar. Your wish is our command, and we will be diving deep into TestCafe and its integration with LambdaTest in this blog.
Many readers are interested in knowing more about TestCafe’s unique features compared to Selenium. In this article, I am going to discuss two TestCafe’s features, one is unique to TestCafe (mobile web app testing), and the other one is more accessible compared to Selenium (concurrent and parallel testing). Limited by the length of the article, I am not going to provide all the Selenium implementation details.
In this article, we will take a closer look at how we can run automated cross-browser acceptance tests in real browsers on LambdaTest using TestCafe as our test framework. LambdaTest is a modern and fast browser testing service with powerful features when it comes to automated cross-browser testing. It provides advanced features like Selenium Grid to automate Selenium testing in the cloud.
TestCafe is a new, open-source, Node.js based e2e testing framework. It's an excellent alternative to Selenium-based tools since it injects itself into the website as JS scripts, so it's more stable and faster. This allows TestCafe to run on any browser, including mobile devices and cloud services as well. It doesn't need Selenium to start your browser window, execute the tests in it and provide useful test report after the execution.
Every application needs testing and most of them need End-to-End (E2E) testing. The quickest way to have E2E tests is to do them manually, but repetitive manual work costs far too much for a company. Automation can help reduce the costs of running End-to-End tests and increase the confidence of a team at the same time. It's true that configuring an E2E test runner and including it into our development workflow isn't an easy task, but once you're done, you never look back. We benefit from more confidence in our code with every single test written, and ensure that the combined pieces of an application, or system, work in perfect harmony.
I want to share our experience at TESISQUARE (www.tesisquare.com) in the process of adopting automation. Some of the things can sound obvious but IMHO reviewing it is a must to avoid wasting your time and resources.
In one of our recent projects at my company, we started using TestCafe for end-to-end UI automation. This article will describe how we ended up choosing TestCafe as the choice of framework for front end automation.
End-to-end testing used to follow a very conservative approach. Everyone was using Java/Python/Ruby with Selenium and it really felt that there is no good alternative to this setup. Selenium was everywhere and at some point, it even transformed its protocol to W3C standard. Ok, we have a W3C standard now, so why do we need alternatives?
A while ago I was setting up integration testing at work for a react app, since we were using GitHub actions to run unit tests it make sense to use the same setup for Integration tests as well. We decided to use the TestCafe to write those tests. This is going to be a very short article about how to run Integration tests for ReactApp with GitHub Actions.
TestCafe is great. It makes it super simple to add e2e testing to your repertoire, making you not only the front-end engineer but the QA engineer too. In my time using TestCafe I have run into situations that I think are common to most test suites. Doing something like creating/deleting user data before and after tests while using concurrency can give you some trouble. I'll show you how I've setup a project to handle this situation.
Two frameworks have appeared on the scene recently eschewing the long held belief that end to end testing of web applications means building upon Selenium. Cypress and TestCafe are similar in many ways but have some important differences.