Stefan Dirnstorfer
CTO
he
I am Open to Write, Speak, Mentor
Stefan Dirnstorfer is the CTO at testup.io, where he focuses on creating an entirely visual workflow for test automation. With many years of experience as a software developer, he has now dedicated himself to a new mission in software quality assurance.
Achievements
Certificates
Awarded for:
Achieving one or more Community Stars in five or more unique months
Activity
earned:
A software tester’s guide to the art of mocking
earned:
A software tester’s guide to the art of mocking
earned:
How to write visual UI automation tests using graphics instead of complex locator strings
is Open to Mentor
is Open to Speak
Contributions
Decide when to stop testing by weighing up the costs, benefits, risks, and impact on quality.
Learn when to use mock testing to create effective and challenging test scenarios
Mock objects are lookalikes that replace external systems to help maintain testability. For example, instead of pulling live weather data, a mocked service can return predefined temperatures, allowing testers to verify the display without relying on the real service. Mocks can be difficult to build and maintain, especially when the external service evolves. However, they are useful when components are slow, unavailable, indeterministic, under development, or require rare responses.
Test setups vary based on the number of mocks used:
Component tests mock everything except the tested module.
Integration tests replace some or most components with mocks.
End-to-end tests use real components whenever possible.
Mocks can be implemented via MockServer, Mockoon, Mocki, or frameworks like JMock and Mockito. Dependency Injection helps swap components efficiently. Some systems allow modifying components to serve as their own mock or using control interfaces and test-specific triggers (e.g., a test user named "CrashAtStepX").
Improve user satisfaction and software resilience by prioritising thoughtful error messaging and a good error culture
Where to click and where to look? These are the questions that need to be defined in an automated UI test script. Why not use images to show it, rather than text to describe it?