12 Testing - Reference Documentation
Authors: Andres Almiray
Version: 1.2.0
12 Testing
Automated testing is seen as a key part of Griffon, implemented using Groovy Tests. Hence, Griffon provides many ways to making testing easier from low level unit testing to high level integration tests. This section details the different capabilities that Griffon offers in terms of testing.The first thing to be aware of is that all of thecreate-* commands actually end up creating unit tests automatically for you. For example say you run the create-mvc command as follows:griffon create-mvc com.yourcompany.yourapp.simple
griffon-app/controllers/com/yourcompany/yourapp/SimpleController.groovy, but also an integration test at test/integration/com/yourcompany/yourapp/SimpleControllerTests.groovy. What Griffon won't do however is populate the logic inside the test! That is left up to you.
As of Griffon 0.9, the suffix of Test is also supported for test cases.
Running Tests
Test are run with the test-app command:griffon test-app
------------------------------------------------------- Running Unit Tests… Running test FooTests...FAILURE Unit Tests Completed in 464ms … -------------------------------------------------------Tests failed: 0 errors, 1 failures
target/test-reports directory.You can force a clean before running tests by passing-cleanto thetest-appcommand.
Targeting Tests
You can selectively target the test(s) to be run in different ways. To run all tests for a controller namedSimpleController you would run:griffon test-app SimpleController
SimpleController. Wildcards can be used...griffon test-app *Controller
Controller. Package names can optionally be specified...griffon test-app some.org.*Controller
griffon test-app some.org.*
griffon test-app some.org.**
griffon test-app SimpleController.testLogin
testLogin test in the SimpleController tests. You can specify as many patterns in combination as you like...griffon test-app some.org.* SimpleController.testLogin BookController
Targeting Test Types and/or Phases
In addition to targeting certain tests, you can also target test types and/or phases by using thephase:type syntax.Griffon organises tests by phase and by type. A test phase relates to the state of the Griffon application during the tests, and the type relates to the testing mechanism.Griffon comes with support for 3 test phases (To execute the JUnitunit,integration, andother) and JUnit test types for theunitandintegrationphases. These test types have the same name as the phase.Testing plugins may provide new test phases or new test types for existing phases. Refer to the plugin documentation.
integration tests you can run:griffon test-app integration:integration
phase and type are optional. Their absence acts as a wildcard. The following command will run all test types in the unit phase:griffon test-app unit:
spock test type to the unit andintegration phases. To run all spock tests in all phases you would run the following:griffon test-app :spock
integration phase you would run...griffon test-app integration:spock
griffon test-app unit:spock integration:spock
Targeting Tests in Types and/or Phases
Test and type/phase targetting can be applied at the same time:griffon test-app integration: unit: some.org.**
integration and unit phases that are in the page some.org or a subpackage of.
12.1 Unit Testing
Unit testing are tests at the "unit" level. In other words you are testing individual methods or blocks of code without considering for surrounding infrastructure. The following is an unit test created using the default templateimport griffon.test.*class SomeUnitTests extends GriffonUnitTestCase { protected void setUp() { super.setUp() } protected void tearDown() { super.tearDown() } void testSomething() { } }
12.2 Integration Testing
Integration tests differ from unit tests in that you have full access to the Griffon application within the test. The following is an integration test created using the default templateimport griffon.core.GriffonApplication import griffon.test.*class SomeControllerTests extends GriffonUnitTestCase { GriffonApplication app protected void setUp() { super.setUp() } protected void tearDown() { super.tearDown() } void testSomething() { } }
startup(), ready(), realize() and show() methods).The type of application to be run depends on the type of project and/or a configuration flag as explained next:
- if a configuration flag
griffon.application.mainClassexists then its value will be used (assumes the value is a literal full qualified class). - if the project is an addon then it will use
griffon.test.mock.MockApplication - finally it will fall back to
griffon.swing.SwingApplication
12.3 Mocking
Mocking is but one of the many alternatives you have at your disposal to reduce complexity while setting up a test that requires a good number of components to be setup before actually testing the real class under test. Griffon provides a few mocking helper methods and classes, which will be discussed next.12.3.1 MockGriffonApplication
MockGriffonApplication is a fully functional GriffonApplication with the advantage that it lets you override the location of all configuration classes: Application, Builder, Config and Events.
If you choose to change the default UIThreadHandler then you must do it so right after the application has been instantiated and no other operation that requires multi-thread access has been called, otherwise you won't be able to change it's value.
By default, a MockGriffonApplication defines the following:
MockApplication- setups a 'mock' MVC group with 3 elements:MockModel,MockViewandMockControllerMockBuilderConfig- defines a single builder entry:griffon.test.mock.MockBuilderMockConfig- defines a single config entry:mocked = trueMockEvents- defines an event handler for 'Mock'
MockBuilder- a single node namedmockthat returns a map with any properties that were defined on the node.MockModel- a lone observable propertyvalueof type String.MockView- simple script that calls themocknode defined by the builder.MockController- a controller with no actions.