TEST THE RISK!

Integration testing has an important role in the test pyramid, it aims to test the integrations of the software products in the integration environments. This means that the software should be built and deployed to an integration test environment and then run the test against the version in the testing environment. If anything wrong occurs as a regression issue then the CI gives feedback about the failures. As a result, the issue should be fixed and built and deployed to the integration test environment. Therefore this process is very expensive and is so late for the modern approach to SDLC, for the shift-left approach. As a solution to this problem, we should consider testing the integration isolatedly within the context of the software itself. Contract testing is an approach to testing the integration depending on the written contract during the build phase. In this post, I want to explain the importance of contract testing. What is Contract The contract is a document created by the

Testing will be more efficient when testers and developers work in collaboration. Especially when it comes to automated testing, we have many challenging points that should be solved with the help of the other team members. This is a basic explanation of the cross-functional team. For mobile application automated end-to-end testing, this cross-functional team approach can be easily applied by contributing the same code base so native toolings give us this. This can increase the quality of the tests code and the framework by the feedback from the developers, and increase the quality of the tests by the feedback from the testers. In this post, I want to give some idea about the benefits of using native mobile automation toolings such as Espresso and XCUITest. What is Native Tooling Native mobile automation toolings are integrated libraries to the mobile application development framework so that developers can write UI tests for the products under development. Native toolings are part o

In this post, I want to give you some practical information about a monitoring system for automated tests. I will touch the following topics: Why we need a monitoring system for automated tests What are the potential benefits of the monitoring system A simple approach using the following technologies: Elasticsearch Kibana Firebase test lab, gcloud and gsutil XCTest and Espresso What is the Centralization of Log Systems In a development pipeline, we have a variety of tools and technologies with different languages and scripts. CI/CD pipeline is a good place the see the process of the development, but to get the detail of an item in the pipeline, we need to get into that item and tackle with logs and data. Some times this investigation requires some capabilities to understand it. One of the easiest ways to get a common understanding from the logs in the pipeline is using one easy tool for the whole process. When we collect all the

Automated tests for API and services are very important so there are lots of solutions for API test automation in the market. These solutions can be commercial-off-the-shelf (COT) or opensource libraries also, there are many frameworks created around these opensource libraries. Testing APIs with tools that have IDE can be easy to start and learn but it can be challenging to customize for your unique problems or integration to CI/CD tools can be hard. Therefore I can suggest you use one of the opensource libraries by implementing it with your favorite language. In this way, it can run faster,  easily extendable, and configurable.  I have created a framework with Airborne and Rspec for automating API tests, you can  check it from Github .  In this post, I want to explain what is Airborne and how I implemented a framework around it. You can simply update the environment variables and write your specs file in the ` specs ` folder.  What is API Testing API stan

Espresso is not designed to play with UI objects. When you are considering it in terms of capability for testing, it needs to be improved more. It is not as mature as Android SDK itself so you need to customize somethings to handle your requirements. Even you may need to use other tools like UIAutomator integrated into your test suite. In this post, I want to show how we can handle getting the text of ViewInteraction view.  ViewInteraction view does not have .text function for getting the text of the object since it is designed to interact with the object. Another method which may solve the problem of the assertion is to use the .check for matching the text, as follows: However, this method is not a good way to assert that a certain field text equals a value. For this purpose, we need to get the text of the element and assert it. To get the text of the ViewInteraction element, we need to cast it to TextView with getting the assignable form of it then

Postman seems to become a defacto tool for service testing because the Postman is very user-friendly, easy-to-learn, all-in-one, lightweight and collaborating tool. Postman has been used for a long time but recently it has growing popularity because of a stable native application, collaboration feature after version 6.2, sharing of collections for team, interactive working with the team, mocks for isolated testing, environments for running the test for different test environments such as local, development, stage ... and many more features. For me, one of the biggest features is easy-to-use for everyone in a team so everyone in a team can use and update a postman collection easily. In this post, I want to explain how postman can be used efficiently. Testing a Service and Writing Tests With postman testing service is simple. Postman supports many methods like POST , GET , PUT , PATCH . Just select the correct method and hit the service URL you want to test. Postman also has everyth

If you are using Capybara with Cucumber, tagging is a very efficient feature of the Cucumber for manageable test cases. Tagging can be also used for managing test environments, like @test may mean that these tests run only in the test environment so set the environment as the test for me. Likely @live may mean that these tests can run on the live environment, assume that you are applying continuous testing. You can also give the scenarios for device-specific tags, like @ihphone6_v may say these tests are for iphone6 with the vertical mode. Moreover, with tagging, you can also make an isolation strategy for running your test in parallel. Each parallel suits should have its own data like users, active records, address, credit card info, and ext. I have used the tagging for running tests in dockers. In this post, you can find some practical way of running Capybara with Cucumber in Dockers. Creating Docker Image: Dockerfile I am using Ruby version 2.3 so in Dockerfile gett