Thucydides Release 0.9.95 – Example reporting for junit tests
Example reporting comes to Junit tests
Our latest release (0.9.95) brings the example reporting format changes (released last month for jBehave) to parametric junit tests. A few cosmetic changes have also been done for better organization of information and improved readability.
Let’s look at these changes in detail.
As the screenshot above demonstrates, the test table on main report page reduces clutter by showing test results at a test-method level instead of a separate row for each parameter set.
The details page will list all parameter sets in a table. By default, the parameters are names “Parameter 1”, “Parameter 2” and so on. But this can be configured with a comma separated list of column headings passed as an attribute to the @TestData annotation.
@TestData(columnNames = "Word,Definition") public static Collection<Object[]> testData() { return Arrays.asList(new Object[][]{ {"apple", "A common, round fruit"}, {"banana", "An elongated curved fruit"} }); }
Further, the steps section will show a collapsed view with a row for each parameter set. The icon can be clicked to expand the top level step to reveal all the steps and corresponding screenshots. Failed test examples will be highlighted in red.
Support for Firefox preferences
A new property firefox.preferences
can be used to supply a semicolon separated list of Firefox configuration settings. For ex.,
-Dfirefox.preferences="browser.download.folderList=2;browser.download.manager.showWhenStarting=false;browser.download.dir=c:\downloads"
Integer and boolean values will be converted to the corresponding types in the Firefox preferences; all other values will be treated as Strings. You can set a boolean value to true by simply specifying the property name, e.g. -Dfirefox.preferences=app.update.silent
.
For the lazy, here’s a complete reference to Firefox’s configuration settings – http://kb.mozillazine.org/Firefox_:_FAQs_:_About:config_Entries
Support for test count based batch strategy
Thucydides makes it possible to split the web tests into smaller batches, and to run each batch on a different machine or different virtual display. This is achieved by specifying two parameters when you run each build: the total number of batches being run (thucydides.batch.count
), and the number of the batch being run in this build (thucydides.batch.number
).
For example, the following will divide the test cases into 3 batches (thucydides.batch.count
), and only run the first test in each batch (thucydides.batch.number
):
mvn verify -Dthucydides.batch.count=3 -Dthucydides.batch.number=1
However, this strategy divides the test cases equally among batches. This could be inefficient if some of your test cases have more tests than others. This release adds a new batching strategy based on number of tests in the test cases. The strategy is implemented with the help of a TestCountBasedBatchManager
which evenly distributes test cases across batches based on number of test methods in each test case.
Dear John Smart and all members of Thucudides team
I use your Thucydides platform to implement regression tests for my site. First of all I want to say ‘thank you’ for all your work. It is a good point to create unified approach for tests implementation in BDD terms. Reports are really cool as well.
And this is my story…
Site feature of Thucydides reporter is an ability to display something in report if it has been passed as @Step method parameter. So, I can create empty @Step method and use it as logger for some messages. It is very simple set of loggers for different circumstances.
@Step public void log(String key, String value) { }
@Step public void log(HashMap m) { }
@Step public void log(ArrayList<HashMap> a) { }
Next step was an discovery that I can pass not only casual strings, but a piece of HTML markup and make my reports cooler.
For example, we have a step which do nothing but print its single parameters to report.
// this is a real Thucydides step without anything
@Step public void description(String html) { }
…and one more method to invoke previous one. This is not a @Step but wrapper for it.
public void about(String description, String… remarks) {
String html =
“” + description + “” +
“Remarks:” +
“”;
for (String li : remarks) html += “” + li + “”;
html += “”;
// send HTML to empty step to display in report
description(html);
}
Inside @Test method we just need to invoke ‘about’ wrapper method with mandatory description and several remarks. Something like this
uni.about(“Shipping method from SMP should be displayed on cart summary page”,
“This is a test for guest user”,
“This test is a checker for shipping method selector on SMP”,
“Site should has at least 2 shipping methods”
);
All was OK but casual archetype upgrade from 0.9.90 to 0.9.95 has brought a bad news.
This is a result for 0.9.95
http://tinypic.com/r/117xlhx/6
‘Description’ is not good.
This is a same result for 0.9.90
http://tinypic.com/r/330aakn/6
‘Description’ step looks better.
I think that escaping for all step parameters is killing a really good feature. (Maybe it is a side feature but it looks really good). And do not forget about ability to embed JavaScript into reports in this way.
It is almost infinite potential for report customization for every programmer!
Best regards, Alex Artukh.
Sorry, but HTML tags inside string literals in Java code have been removed.
But you still see result on the first screenshot.
This is very cool! I’ve changed the reporting so that only non-ascii chars are escaped (e.g. non-English letters), rather than everything. You can try this out with the 0.9.98-SNAPSHOT.
By the way, you should write a blog entry on this! (We’d be happy to post it on one of the Thucydides-related sites)