Alex Martins, advisor for continuous testing at CA Technologies:
The main differentiator for us is removing the barrier for Test Driven Development and Acceptance Test Driven Development. In TDD and ATDD, teams typically need to think through the requirements they have to write the code for and then think about the test, which usually is a barrier for adoption. Our solution at CA is to remove that barrier. We are able to automatically generate the acceptance tests for the developers to just start coding against as well as the unit level tests for them to start coding against for TDD and ATDD.

There are three solutions that form the core of our TDD and ATDD solutions: CA BlazeMeter API Test, CA Agile Requirements Designer, and CA Test Data Manager.

Thomas Hooker, vice president of marketing at CollabNet:
CollabNet views Test Driven Development as a continual evolution in our overall industry’s goal and purpose to build better and better software. What we do is we embrace different methodologies and different tools that enable our customers to adequately test their software, and to have the testing components drive the software development life cycle if that is what the customer chooses to do.

We are an open platform and we allow you to construct test patterns that best suit your enterprise. We fully support your efforts to move towards a CI/CD world where we do have continuous integration, continuous development and continuous deployment. What that really does is that enables the developer and the development organization to take much more responsibility for testing individual items and features directly. After that has taken place, you have your standard test harnesses that your standard quality assurance organizations would be running and utilizing to ensure quality as you move downstream, but in a test driven environment.

Kelly Emo, director of life-cycle and quality product marketing at Hewlett Packard Enterprise:
We don’t offer a Test Driven Development tool itself, but we offer support for Behavior Driven Development (BDD) as part of our ALM Octane management platform. We are also able to integrate with open-source and developer tools that support TDD and bring up that information into the ALM Octane layer so your agile team and your application owner or your product owner continuously know the state of their quality and to know the state of their team’s velocity.

The other thing we are able to do is because Test Driven Development is the practice, the tests are often written in unit frameworks like NUnit or JUnit, so we can utilize the output of those frameworks to accelerate regression test and business process test. The whole flow, the whole business process you would automate using our Unified Functional Testing solution, is already there as part of that Test Driven Development process. We can just plug that right in. Think of it as building blocks, the TDD functions that are done in the open-source tools become building blocks to the automated tests that are created in our tools.

Walter Capitani, product management for Klocwork at Rogue Wave:
The way we certainly support it is through the execution of tests that you don’t have to write. In other words, you are going to do your TDD by writing your own test for your own functionality, and then we are going to add to those tests with a series of quality and security tests that will generate the same kind of results in terms of finding places where your software is not behaving properly, where it has crashed, or where it has security vulnerabilities, and enable you to then develop solutions to those issues which will then cause the tests to pass. Klocwork can find more than 500 defects in your code, so by running those tests in addition to the specific tests you have written, it gives you a bigger bank of tests for which you are going to develop against.

Where I think the TDD gap exists today is between functionality and actual proper operation — reliable, secure operation. There are many ways to achieve that, but many of them are expensive either from a time or actual cost perspective for many software vendors out there and that is where I feel like there are tools that instead of building it itself, you can use tools such as static code analysis to help bridge the gap.

Jason Hammon, director of product management at TechExcel:
We do have tools in place that allow you to do Test Driven Development, or a process like that. What we do is we allow requirements from our repository to be created as tasks for developers and one of those tasks that you can certainly use is a test based on that requirement. It is really easy and lightweight for a developer to just grab the requirements that are new, and put them into their sprint or whatever sort of time tracking they want to do along with those tasks to ensure for each of those requirements they have run a test corresponding with it.

Our solution does about whatever development methodology you want to use, and we are not going to limit you into one particular method; because we have an open platform that integrates lots of third-party tools, you could even use our solution in conjunction with other development tools to perform TDD so if you are using something else for your CSM tool or another bug-tracking tool, you can integrate those with our requirements management tool and still have a process like that.