10. 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 the `create-*` 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

Not only will Griffon create an MVC group with a controller at `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

The above command will produce output such as:

    -------------------------------------------------------
    Running Unit Tests…
    Running test FooTests...FAILURE
    Unit Tests Completed in 464ms …
    -------------------------------------------------------Tests failed: 0 errors, 1 failures

Whilst reports will have been written out the `target/test-reports` directory.

> You can force a clean before running tests by passing `-clean` to the `test-app` command.

##### Targeting Tests

You can selectively target the test(s) to be run in different ways. To run all tests for a controller named `SimpleController` you would run:

    griffon test-app SimpleController

This will run any tests for the class named `SimpleController`. Wildcards can be used...

    griffon test-app *Controller

This will test all classes ending in `Controller`. Package names can optionally be specified...

    griffon test-app some.org.*Controller

or to run all tests in a package...

    griffon test-app some.org.*

or to run all tests in a package including subpackages...

    griffon test-app some.org.**

You can also target particular test methods...

    griffon test-app SimpleController.testLogin

This will run the `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 the `phase: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 (`unit`, `integration`, and `other`) and JUnit test types for the `unit` and `integration` phases. 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.

To execute the JUnit `integration` tests you can run:

    griffon test-app integration:integration

Both `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:

The Griffon Spock Plugin is one plugin that adds new test types to Griffon. It adds a `spock` test type to the `unit` and`integration` phases. To run all spock tests in all phases you would run the following:

    griffon test-app :spock

To run the all of the spock tests in the `integration` phase you would run...

    griffon test-app integration:spock

More than one pattern can be specified...

    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.**

This would run all tests in the `integration` and `unit` phases that are in the page `some.org` or a subpackage of.