By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.

DevMate is becoming Vizitest - a brand new way to do Unit and Integration testing!!

You will be redirected to in 10 seconds

Go to now

If you are looking for DevMate Documentation, press the button below.

DevMate Documentation

Or you can go to the DevMate home page.

DevMate Home
"All code is guilty, until proven innocent."
"The bitterness of poor quality remains long after the sweetness of meeting the schedule has been forgotten."
"Why do we never have time to do it right, but always have time to do it over?"

How DevMate works

Bullet icon
Eliminates almost all hand coded tests
Bullet icon
Drops straight into your IDE
Bullet icon
Boosts software quality
Bullet icon
Works with your preferred test runner
Bullet icon
For Developers, Product Owners, QA Engineers and Domain Experts
Bullet icon
Slots into any Cl/CD and automation workflow
How it works Part 2
How it works part 1

Helping the whole Product team

DevMate brings structure to the way your product team thinks about testing.
venn diagram
Product Specialists
Expand text
Visualize your tests

DevMate generates test code automatically and that's a big win. However, DevMate helps Developers, QA Engineers and Product Owners easily visualize each test now or years later.

Fully configured test definition


DevMate generates unit and integration tests, but it also helps share the responsibility of test case definitions with the rest of the product team.

You'll be delighted to know that you don't need to change your development configuration at all. Develop in your preferred IDE and no need to work with special test runners or other "magic" tools.

Developers will spend up to 50% less time configuring  tests and more time on functional coding.


DevMate will change the way you and your team think about testing. We facilitate not just unit and integration testing, but a requirements led approach that brings structure, drives serious quality and can involve the whole team, not just developers.

As one of Europe’s top Software Quality Management consultancies, we can support your team not just with DevMate services but also a broad range of Software Quality and Process Management services.

PMs, POs, Domain Experts and QA Engineers

The highest quality levels are achieved by making sure that tests are properly requirements led. Requirements are often best understood by domain experts, product managers, product owners and QA Engineers.

DevMate lets the broader product team share responsibility for quality by encouraging them to be involved in the requirements and test case definitions.

Supported Technology

DevMate currently supports the following IDEs and languages
c sharpJava IDE
IntelliJ IDEVisual studio IDEEclipse IDE

Quality related services and support from one of Europe's leading consultancies.

Over 300 companies trust our sister company Software Quality Lab to deliver the highest quality training on DevMate, Test Automation, Management & Process, Agile, Requirements Modeling, Code Quality and Project Management.

T Systems logoLiebherr logoONB logoSiemens logoBosch logoPorsche logoThyssen Krupp logoAustria telekom logo

Equations for success

As a leading consultancy firm, we have a deep understanding of testing methodologies and software engineering.
Unit Testing ≠ Quality

Writing lots of unit tests says little about actual quality. What matters is writing great unit tests. Blindly unit testing everything frustrates developers, requires more maintenance and leads to testing not being taken seriously.

Black Box Testing = Quality + Happiness

Black Box Testing done well leads to better code quality, less time writing unnecessary unit tests, more time writing functional code and, as a result, improved developer happiness.

1 Unit Test Case ≠ Adequate

When time is tight, we often see only one Happy Path unit test for a given method.

This is rarely adequate as there are typically many paths, some of them critical, that should be covered by tests.

If only the Happy Path is covered by unit tests, this shifts the testing responsibility to higher levels in the testing pyramid (Integration and End to End /UI tests). The net effect is that errors inevitably get through to the customer.

A requirements led, black box approach is usually the best way to deliver high quality tests and therefore high quality.

Great Code Coverage ≠ Great Quality

A lot of companies we talk to focus heavily on code coverage. But this says nothing about whether the requirements are really being properly tested and so is a very unreliable indicator of quality.

TDD or Black Box Testing involves POs and Domain Experts which means less time wasted writing potentially meaningless tests or missing important test cases.

Read our article Obsessed with Code Coverage?

White Box Testing ≠ Requirements Met

White box testing can be very important in certain situations. However, white box tests can usually only be implemented by a developer as the functional code needs to be fully understood first. And a White Box Test does nothing to confirm whether the requirements are being met.

Black box testing is, in most cases, a better way to go because it is fully requirements led. This also allows the developer to share responsibility for test definitions with Domain Experts, POs and QA Engineers who anyway best understand the requirements. Developers will spend more time writing functional code and less time writing unit tests as a result.

TDD = Black Box Testing

We often see companies not making this connection clearly. If you are following TDD principles then you are, by definition, performing back box tests and are focusing on requirements.

As black box testing approaches are important for validation of the code (does the implemented code meet the requirements?), TDD and Black Box Testing are essentially synonymous.

Of magic and asymmetric relationships

We're bigs fans of cutting edge technology. However, we also know that too much magic, used the wrong way, can create many more problems than solutions.
Witch on broomstick
Pulling back the curtain
Expand text
1 million tests ≠ Quality
Expand section arrow
An example AI generated test
Expand section arrow
The problem with magic tools
Expand section arrow
Asymmetric relationships
Expand section arrow