Build a Meta-Testing Framework for JUnit-style XML Test Results

As part of a xUnit Test Patterns training course I offer in multiple programming languages, I have a bunch of exercises each consisting of tests written in each programming language. For the JUnit test exercises, I have meta-tests written in JUnit that run a suite of JUnit tests and compare the results to the expected results (#run, #failed, #errors, list of failed/errored test names and error messages). I would like to be able to do this for all languages in which I currently have or plan to offer the training to ensure that each language-specific set of material is giving me the same result. Task 1: Define Strategy $100 USD Come up with a strategy and price for implementing this that works for multiple xUnit testing frameworks (probably JUnit4, NUnit 3.x, Mocha and CppUTest). The selection criteria for *this* task is based on your response in which you should describe your experience with xUnit test frameworks and how you would go about defining the strategy (which would include a list of software to be (re)used, extended (e.g. Ant/Jenkins tasks/steps) and/or implemented from scratch, and a price for doing so.) I *may* award this project to several responders in parallel (yes, each would get the full fee) and choose who does task 2 based on the approach proposed. See Task 2 for the selection criteria for who gets to implement task 2. Task 2: Implement Framework for chosen xUnit test runners TBD (probably JUnit4, NUnit 3.x, Mocha and CppUTest). I will award this project once I have selected a strategy based on responses to Task 1. The people who worked on task 1 will obviously have an advantage when bidding on this project. The selection criteria for the strategy will include how simple the solution is (less code is better) and robust the solution will be to future changes by other parties. The exact set of xUnit framework interworkings to be ipmlemented will depend on the strategy chosen and how generically it interacts with the test runners. (Yes, more generic is better; ideally, no new code would need to be written to add another xUnit commandline tool other than a way to configure the command-line arguements.) Examples of a Strategy: Using "standard" JUnit-style XML Output: Many build tools like Ant and Jenkins have tasks/steps to run a suite of tests and fail the build if the number of test failing or erroring > 0. Most of these tools examine an XML output file that the command line test runner of unit testing framework provides. And most such command line test runners can be configured to output a standard format XML file that was pioneered by JUnit (and possibly extended by other frameworks as needed.) Some provide their own XML formats E.g. [login to view URL] And some of those provide XML transforms to the JUnit 3 XML format. E.g. [login to view URL] Some frameworks have custom plugins for Jenkins or Ant E.g. [login to view URL] Another strategy could be to build on top of a tool such as [login to view URL] and/or Danger-JUnit to parse the test output log.