Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Rate Macro

Table of Contents

Introduction

Magnolia uses JUnit 4 and if dynamic mocks are required Mockito (new) for creating unit tests. Before we were using EasyMock for dynamic mocks.

...

General SetupSpecificsPreferred ApproachExample
Class under tests operates on JCR Nodefew calls to common methods of the NodeMockNode if it supports those calls, Mockito mock else 
 need a simple hierarchy of NodesMockNode if it supports those calls, Mockito mock else 
 need a simple hierarchy of Nodes but with several propertiesuse SessionTestUtil to instantiate MockSession + MockNodes from propertiesStream or String 
 need a complex hierarchy of Nodes, real NodeTypes or issue real queriesuse RepositoryTestCase 

 

Naming

A test class should end with Test. Typically, it will have the exact same name (and package) as the class it tests, with the Test suffix.

If you’re writing a test class meant to be re-used as a super class (e.g RepositoryTestCase, suffix it with TestCase; this will exclude it from execution. (it would otherwise fail, because it likely has no @Test methods)

Methods: since we’re using jUnit 4, there is no need to prefix method names with test. Choose a method name that describes what the test asserts. (fooDoesBarWhenX())

Self tests: if you need to test methods of the test class itself (e.g utility methods that the tests use need to be themselves to validate their behaviour), do that in a method called selfTest(). If there are multiple such test methods, refer to the point above.

If you’re testing a reusable test class, two options:
- don’t suffix it with TestCase, but just with Test and use selfTest() methods.
- if that’s not applicable, FooBarTestCaseSelfTest might seem a little over the top.

In some cases, we also want to test external libraries. In particular, when a certain Magnolia feature relies on a specific behavior of such library, we might want to assert that it indeed does behave the way we think it does, and that it continues on doing so in their future releases. For such cases, selfTest methods can help, but if we’re testing more than that, then we can envision FooBarLibTest classes (where FooBar is the class under test, and LibTest is the suffix) - we’re “testing the libs of FooBar”.

Resources

Mock Object: http://en.wikipedia.org/wiki/Mock_object

...