The user interface (UI) is an important part of the functionality of Android mobile apps, so you should be able to perform extensive UI tests. Google’s Mona El Mahdy has published has published on the Google Software Testing blog a post that presents four strategies to test Android UI, aiming to create UI tests that are both fast, reliable and easy to debug.
So your team has made the transition to agile and your work is broken down into user stories. It makes perfect sense to break work down into smaller chunks, but now you’re running into problems with estimation and communication. Your team is delivering value but it’s been discovered that user stories are thrashing through the analysis, development and QA processes. What is going on here? Come a software development process with a deceiving name: Behavior Driven Development.
Context Driven Testing can be defined by a is a set of values about software testing that recommends a continuous and creative assessment of the software testing activities based on the current knowledge about the situation and the value of the tests for the organization.
One of the famous concept in software testing is the testing pyramid defined by Martin Fowler that is based on strong unit tests and has less user interface (UI) tests at the top. Sometimes organizations have a different view of software tests and the pyramid is not a pyramid anymore. In this blog post, Fabio Pereira discusses the case where the pyramid looks like a cupcake.
This presentation pulls a variety of examples in testable development from the speaker book “Continuous Enterprise Development in Java” published by O’Reilly. It includes a review of the sections on RESTful services, UI verification, transactions and security.
Writing test should be part of the normal routine of every software developer. It is however not always the case. In his book ” Bad Tests, Good Tests”, Tomek Kaczanowski provides some interesting tips to improve your test writing activity.
Two years ago, we introduced Spock tests into the MongoDB Java driver. The decision could be considered controversial – the project used no external dependencies in production code, and was 100% Java. But there was a back door… with Gradle as the build system, there was a tiny excuse to use Groovy in the project, provided it was not in the production code. That was all the excuse we needed to start using Spock for unit and later, integration tests.
Copyright © 2009-2024 Software Testing Magazine by Martinig & Associates