#TQXR
TQXR is a placeholder name for an approach to QA-2.0, in this case, "Quality Automation" which is a re-definition of the initialism. QA-2.0 is a work in progress, that encompasses not only quality automation, but seeks to relieve brain-enabled (read human) quality analysts from the tedium of (pointless) repetitive tasks assiciated with "testing". This is in conjunction with the effort to remove waste from the development process, and facilitate "shift-left". Down-time associated with "waiting for regression" or "waiting for QA" is a waste which can be significantly reduced by adopting TQXR practices, say, as part of a devops transformation.
CI/CD can be "supercharged" with a re-tooled and efficient QA application. Part of that re-tooling is the moving of "old test scripts" to a newer, more engineered application design.
TQXR does not actually mean anything, or stand for anything. I just bought a four-letter domain name which happened to be this.
#The QA Seed.
The project is designed to be a kick-starter project for Quality Automation to drive the development of an automated testing framework using the principals of clean code and test driven development.
The project utilises Spring Boot for component dependency management and for things like dependency injection and auto configuration of regularly used application building blocks (like JPA/MySql or JMX/ActiveMQ).
There are a number of examples which illustrate how the Spring technologies are utilised, and some discussion
of their suitability - sometimes @Autowired fields on a unit test class is simply overkill - slowing the tests
and increasing their scope and verbosity.
An attempt is made to pare back the technologies where appropriate in order to provide a testing skeleton project which is easily customised to point at a system under test.
In order to make things really easy, some very basic and generally portable tests are included which can ensure the full weight of the project is ready for further development once pointed at the appropriate system under test.
The settings for pointing at another system can be found in resources/application.properties.
The default group, which will exclude any tests marked with DeliberateFail or Bloated.
mvn testRunning the cucumber tests is achieved using Spring boot (rather than a JUnitRunner or some such wrapping tech) - this is because the design of this application is such that it is quite deliberately for the verification of a system under test.
As such, the term test is reserved solely for unit testing in this case, and run is used to refer to the 'actual
running of the tests'.
mvn spring-boot:runSome extra things have been done to minimise the output generated by the Spring technologies, such as the banner. To run
all the acceptance tests except those 'work in progress' tests, and only log the output of cucumber :
mvn clean spring-boot:run -q -Dcucumber.options="--tags ~@wip --tags ~@deliberate_fail"To re-enable the Spring banner, alter the setting in resources/application.properties.
#Deliberate Fails
This project includes a reporting class that listens to JUnit during unit test execution and produces a nice colourised report. In order to see it in action, some failing tests have been included which can be seen by omitting the filter tag, eg:
mvn spring-boot:run -Dcucumber.options="--tags ~@wip"This will run a set of JUnit tests that are designed to fail deliberately. The deliberate fails will be reported by the TQXR TestResultListener, eg:
mvn test -Pdeliberate_failsDuring development of the reporting classes, it was handy to be able to run two profiles, showing both passing and deliberately failing unit tests.
mvn clean test -q -Pexample_testsMaven and Spring can be quite noisy which goes against the convention of 'only report on the problem domain' - trying to read a log after a fail on (say) Jenkins can be tiresome if the level of logging is not configured to filter INFO and DEBUG messages.
There is a default setting in resources/application.properties to take care of this, and the setting can be overridden
on the command line for incidental requirements to see what's going on under the hood.
To reduce the noise produced when running unit tests, try:
mvn test -q -Dsurefire.printSummary=falseSetting printSummary to false also suppresses the actual test report produced by the custom listener which makes it
fairly useless to show a nicely formatted report in "agile-dox" style using mvn test and surefire.
To see an agile-dox style report, it would be fairly straightforward to create a script that reads the .xml files in
/target/surefire-reports/ and produces some pretty console output, post test.