One question I get asked a lot is how you can automatically rerun your test on failure. This is a typical case for heavy, functional test scenarios, which are often flaky. While test flakiness and its management is crucial and extensive matter itself, in this post I want to give a shout to the extremely simple yet useful library: Spock-Retry. It introduce possibility to create retry policies for Spock tests, without any additional custom-rules implementation – just one annotation.
If you are not a fan of Spock testing framework and you prefer JUnit – stay tuned! I will post analogous bit about rerunning JUnit tests soon.
In distributed systems architecture, testing becomes much more complex than in monolith architecture. Although only end-to-end testing gives us full confidence of system-wide implementations, we should also test services in isolation. The easiest way to obtain isolation in microservices architecture is to stub external applications.
The problem is that mocks are usually stateless – they simulate application logic with fixed actions, without any conditional behaviour. If we want to test cases like HTTP latency or data redundancy validations, where external service represents different behaviour among repeated calls, simple mocks can be insufficient.
This article by me was originally published on TheServerSide.
There’s a common phrase in testing: if you do something more than once – automate it. Software testing, where we routinely perform similar actions, is a perfect base for automation. In modern software development, with the use of microservices and continuous deployment approach, we want to deliver features fast and often. Therefore, test automation becomes even more important, yet still facing some common problems. Based on my experience, here is my list of top 5 mistakes that teams make in acceptance test automation.
In my last post I wrote about creating Selenium Grid with use of Docker. I’ve received some questions about customising node’s containers – by default, Docker containers for Selenium Grid nodes run only one instance of browser per node. It’s important to understand that running Grid on Docker is slightly different approach than running it alone – instead of building huge Grid with multiple nodes and dozens of browsers, you run few smaller, independent machines. If one machine is down – you throw it away and build another one. Great use case of Selenium Grid with Docker is to build Grid’s machines as a self service for teams in your company, or to build it automatically before automated tests trigger, and destroy it after.
Nevertheless, it is possible to tweak default node’s conteiners, so they would contain more browser instances. In this post we’ll create container with custom Selenium Grid’s node configuration – our container would provide more than one instance of browser. Remember, that if you have an account on Docker Hub, you can host one container for free, so after going through this tutorial you can commit your own container and host it, or just create your own, custom Grid on Docker, tailored to your needs.
Selenium webdriver on it’s own, or with it’s implementation, like Geb is arguably the most popular solution for testing web-based applications. Besides all it’s greatness, it has some flaws. Selenium tests are slow, and it’s cost of maintenance is big. The answer for the first issue is distributed testing with Selenium Grid, which I described previously.
From the DevOps perspective though, setting Selenium Grid configuration like that is highly over-expensive and non-scalable. The answer for this can be Docker with it’s docker-compose tool. In this post we will try to create vm provisioned by docker-compose and set up scale Selenium Grid. All of this will be run with one command.
So, what is this Agile Testing? It’s kind of fancy term and everybody use it in software development and QA world, but do we really understand it? What is different in agile approach to testing than in classic ones?
I will try to highlight core concepts, that stands for Agile Testing approach. Please don’t consider this as any kind of manifesto, rather that I want to summarize list of good practices for testers and QAs working in agile teams.
Software Development domain is well known for buzz-words. With the growth of agile movement, Continuous Delivery (CD) and Continuous Integration (CI) terms become highly popular. One of the best tool supporting the processes of CD and CI is Jenkins.
Jenkins is an continuous delivery and continuous integration server application. Typical use-cases of Jenkins are building your application from version control system, running acceptance tests or deploying application on dev/test/prod environments. Jenkins is free and cross-platform, and it’s web application written in Java, so it comes as a .war file.
In this article, we will perform basic and most common configuration of Jenkins job. Our scenario is to checkout project from git repository and run tests. Last step would be to generate test report.