Warning: Can't synchronize with repository "(default)" (/home/git/ome.git does not appear to be a Git repository.). Look in the Trac log for more information.
Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

User Story #11258 (accepted)

Opened 11 years ago

Last modified 8 years ago

OMERO.server test review

Reported by: bpindelski Owned by:
Priority: major Milestone: Unscheduled
Component: Services Keywords: n.a.
Cc: cblackburn, jamoore, mtbcarroll, pwalczysko Story Points: n.a.
Sprint: n.a. Importance: n.a.
Total Remaining Time: 0.0d Estimated Remaining Time: n.a.

Description (last modified by bpindelski)

This story outlines the scope of work required during the OMERO.server test maintenance phase (summer 2013). The work is to be targeted at the dev_4_4 branch.

  1. Identified problems
  • integration tests are not always inline with how developers perceive the way code under test (server services) would work,
  • integration tests are split and, to some extent, duplicated between Java and Python,
  • the documentation on how integration tests are laid out and how exactly to run them is lacking,
  • unit tests rely on two different pieces of software: JUnit and TestNG, hence use different semantics,
  • test coverage isn’t measured,
  • PRs are often opened without corresponding changes to test classes,
  • OmeroJava is a test-only package and its name doesn’t convey its contents,
  • there is no clear naming pattern among test packages (e.g. unit vs. utest),
  • some of the tests are lacking comments where needed,
  • the testing frameworks (jMock, TestNG) are outdated,
  • other components (e.g. OmeroM) can’t reuse logic used for test scaffolding.
  1. Goals
  • to make the test more useful for developers; simpler and easier to write,
  • to ease the way tests are run and updated,
  • to allow other components of the OMERO codebase to reuse helper classes,
  • to make the integration tests de facto examples of how the unit under test should work,

http://trac.openmicroscopy.org.uk/ome/ticket/1736 seems also to have some tickets relevant to this body of work.

Change History (7)

comment:1 Changed 11 years ago by bpindelski

  • Description modified (diff)

comment:2 Changed 11 years ago by bpindelski

  • Cc cblackburn jamoore mtbcarroll pwalczysko added

comment:3 Changed 11 years ago by agilo

  • Status changed from new to accepted

Updated status, related task in progress

comment:4 Changed 11 years ago by bpindelski

  • Sprint changed from Testing and Docs (1) to Testing and Docs (2)

comment:5 Changed 11 years ago by bpindelski

  • Milestone changed from Testing and Docs to Testing2
  • Sprint Testing and Docs (2) deleted

comment:6 Changed 10 years ago by mtbcarroll

On develop ./build.py -f components/server/build.xml test has plenty of unit test failures before it prints something about pre-instantiating singletons and hangs. As well as integration tests, we probably need to make sure that component unit tests get overhauled and Hudkins-ized.

comment:7 Changed 8 years ago by sbesson

  • Milestone changed from Testing2 to Unscheduled
Note: See TracTickets for help on using tickets. You may also have a look at Agilo extensions to the ticket.

1.3.13-PRO © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.140635 sec.)

We're Hiring!