Qpid
  1. Qpid
  2. QPID-3125

Add junitreport task for readability in Java unit tests

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 0.11
    • Fix Version/s: 0.11
    • Component/s: Java Tests
    • Labels:
      None
    • Environment:

      All platforms. Area of functionality is Java based unit tests.

      Description

      Currently when running the unit tests there is no real convenient way to see what has failed and why. The attached patch makes a modification to the module.xml file for the java tests to allow junit to print a report after the testsuite is run to output the results in html format. The results are placed into

      build/results/<module-name>/report/html

      where module name is one of client, common, systests etc.

      1. module.patch
        0.5 kB
        Weston M. Price
      2. report-module.patch
        1 kB
        Weston M. Price
      3. report-module-v2.patch
        1 kB
        Weston M. Price

        Activity

        Hide
        Weston M. Price added a comment -

        Simple patch file to add junitreport task to module.xml for java based unit tests.

        Show
        Weston M. Price added a comment - Simple patch file to add junitreport task to module.xml for java based unit tests.
        Hide
        Robbie Gemmell added a comment -

        Have you tried running 'ant report' after running the tests?

        Admitedly it isnt module-level as with your patch, but I actually find that preferable since it means you dont need to look in several different places to find the results. The seprate target doesnt force generation of the report files, which is useful if you dont actually want to generate them (I hardly ever do).

        Show
        Robbie Gemmell added a comment - Have you tried running 'ant report' after running the tests? Admitedly it isnt module-level as with your patch, but I actually find that preferable since it means you dont need to look in several different places to find the results. The seprate target doesnt force generation of the report files, which is useful if you dont actually want to generate them (I hardly ever do).
        Hide
        Weston M. Price added a comment -

        Yep, it certainly does. Agreed, I think this is a better approach as well. The only reason for the patch was the split between modules but I agree, it probably doesn't warrant a separate task.

        Show
        Weston M. Price added a comment - Yep, it certainly does. Agreed, I think this is a better approach as well. The only reason for the patch was the split between modules but I agree, it probably doesn't warrant a separate task.
        Hide
        Rajith Attapattu added a comment -

        I'd agree with Robbie. I would also prefer a separate target for report generation. I also prefer the current report format where I can see at a glance the failures, rather than having to go into each module.

        Show
        Rajith Attapattu added a comment - I'd agree with Robbie. I would also prefer a separate target for report generation. I also prefer the current report format where I can see at a glance the failures, rather than having to go into each module.
        Hide
        Weston M. Price added a comment -

        Better solution presented that already exists within the build system.

        Show
        Weston M. Price added a comment - Better solution presented that already exists within the build system.
        Hide
        Robbie Gemmell added a comment -

        Whilst both myself and Rajith prefer the full set of results, that isnt to say we cant have both; I only object to the forced generation of results, I wouldnt actually be bothered by having e.g. 'report-module' as a new module-level build target that generated the alternative style results upon demand.

        To do that you would just need to add a module.xml level target and then use an iterator style target in build.xml (like most of the targets in the build system do) instead of adding it to the test task like your current patch.

        Show
        Robbie Gemmell added a comment - Whilst both myself and Rajith prefer the full set of results, that isnt to say we cant have both; I only object to the forced generation of results, I wouldnt actually be bothered by having e.g. 'report-module' as a new module-level build target that generated the alternative style results upon demand. To do that you would just need to add a module.xml level target and then use an iterator style target in build.xml (like most of the targets in the build system do) instead of adding it to the test task like your current patch.
        Hide
        Weston M. Price added a comment -

        As a result of discussion I am reopening this issue and attaching an updated patch that provides unit test reports for each module within the QPID java framework.

        Show
        Weston M. Price added a comment - As a result of discussion I am reopening this issue and attaching an updated patch that provides unit test reports for each module within the QPID java framework.
        Hide
        Weston M. Price added a comment -

        As a result of the discussion, I am attaching report-module.patch that provides junit reports for each module in the java QPID framework. To execute

        ant test-report-module

        Show
        Weston M. Price added a comment - As a result of the discussion, I am attaching report-module.patch that provides junit reports for each module in the java QPID framework. To execute ant test-report-module
        Hide
        Robbie Gemmell added a comment -

        Just a couple small niggles: for clarity the new build.xml target should also just be 'report-module' so it aligns with the new module.xml task, and the line at module.xml ~L390 should not be removed.

        If you update the patch I'll commit it in the morning.

        Show
        Robbie Gemmell added a comment - Just a couple small niggles: for clarity the new build.xml target should also just be 'report-module' so it aligns with the new module.xml task, and the line at module.xml ~L390 should not be removed. If you update the patch I'll commit it in the morning.
        Hide
        Weston M. Price added a comment -

        Thanks Robbie for both the guidance as well as looking at the patch. I am attaching the updated version.

        Show
        Weston M. Price added a comment - Thanks Robbie for both the guidance as well as looking at the patch. I am attaching the updated version.
        Hide
        Weston M. Price added a comment -

        updated version per comments/suggestions.

        Show
        Weston M. Price added a comment - updated version per comments/suggestions.
        Hide
        Robbie Gemmell added a comment -

        Applied report-module-v2.patch to trunk.

        Show
        Robbie Gemmell added a comment - Applied report-module-v2.patch to trunk.

          People

          • Assignee:
            Robbie Gemmell
            Reporter:
            Weston M. Price
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 1h
              1h
              Remaining:
              Remaining Estimate - 1h
              1h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development