elharo commented on code in PR #597: URL: https://github.com/apache/maven-site/pull/597#discussion_r1905343653
########## content/markdown/plugin-developers/plugin-testing.md: ########## @@ -0,0 +1,154 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Developers Centre - Testing Plugins + +## Introduction + +This document is intended to help Maven Developers test plugins with unit tests, integration tests, and functional tests. + +## Testing Styles: Unit Testing vs. Functional/Integration Testing + +A unit test attempts to verify a mojo as an isolated unit, by mocking out the rest of the Maven environment. +A mojo unit test does not attempt to run your plugin in the context of a real Maven build. Unit tests are designed to be fast. + +Functional tests run much more slowly than unit tests, but they can catch bugs or detect issues that you may not catch with unit tests. + +The general wisdom is that your code should be mostly tested with unit tests, but should also have some functional tests. + +## Unit Tests + +### Using JUnit alone + +In principle, you can write a unit test of a plugin Mojo the same way you’d write any other JUnit test case. + +However, many mojo methods need more dependencies to work properly. Review Comment: Is it Mojo or mojo? I think mojo though I'm not sure, but either way let's be consistent. ########## content/markdown/plugin-developers/plugin-testing.md: ########## @@ -0,0 +1,154 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Developers Centre - Testing Plugins + +## Introduction + +This document is intended to help Maven Developers test plugins with unit tests, integration tests, and functional tests. + +## Testing Styles: Unit Testing vs. Functional/Integration Testing + +A unit test attempts to verify a mojo as an isolated unit, by mocking out the rest of the Maven environment. +A mojo unit test does not attempt to run your plugin in the context of a real Maven build. Unit tests are designed to be fast. + +Functional tests run much more slowly than unit tests, but they can catch bugs or detect issues that you may not catch with unit tests. + +The general wisdom is that your code should be mostly tested with unit tests, but should also have some functional tests. + +## Unit Tests + +### Using JUnit alone + +In principle, you can write a unit test of a plugin Mojo the same way you’d write any other JUnit test case. + +However, many mojo methods need more dependencies to work properly. +For example, you’ll probably need to inject or mock a reference to a `MavenProject`, so your mojo can query project variables. Review Comment: delete "or mock" as mocks still need to be injected. ########## content/markdown/plugin-developers/plugin-testing.md: ########## @@ -0,0 +1,154 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Developers Centre - Testing Plugins + +## Introduction + +This document is intended to help Maven Developers test plugins with unit tests, integration tests, and functional tests. + +## Testing Styles: Unit Testing vs. Functional/Integration Testing + +A unit test attempts to verify a mojo as an isolated unit, by mocking out the rest of the Maven environment. +A mojo unit test does not attempt to run your plugin in the context of a real Maven build. Unit tests are designed to be fast. + +Functional tests run much more slowly than unit tests, but they can catch bugs or detect issues that you may not catch with unit tests. + +The general wisdom is that your code should be mostly tested with unit tests, but should also have some functional tests. + +## Unit Tests + +### Using JUnit alone + +In principle, you can write a unit test of a plugin Mojo the same way you’d write any other JUnit test case. + +However, many mojo methods need more dependencies to work properly. +For example, you’ll probably need to inject or mock a reference to a `MavenProject`, so your mojo can query project variables. + +### Using PlexusTestCase + +Mojo variables are injected by Guice (an open-source software framework for the Java platform), sometimes with a Codehaus Plexus (a collection of components used by Apache Maven) adapter. Review Comment: delete "(an open-source software framework for the Java platform)" as it doesn't add much. Folks can Google it if they've never heard of it ########## content/markdown/plugin-developers/plugin-testing.md: ########## @@ -0,0 +1,154 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Developers Centre - Testing Plugins + +## Introduction + +This document is intended to help Maven Developers test plugins with unit tests, integration tests, and functional tests. + +## Testing Styles: Unit Testing vs. Functional/Integration Testing + +A unit test attempts to verify a mojo as an isolated unit, by mocking out the rest of the Maven environment. +A mojo unit test does not attempt to run your plugin in the context of a real Maven build. Unit tests are designed to be fast. + +Functional tests run much more slowly than unit tests, but they can catch bugs or detect issues that you may not catch with unit tests. + +The general wisdom is that your code should be mostly tested with unit tests, but should also have some functional tests. + +## Unit Tests + +### Using JUnit alone + +In principle, you can write a unit test of a plugin Mojo the same way you’d write any other JUnit test case. + +However, many mojo methods need more dependencies to work properly. +For example, you’ll probably need to inject or mock a reference to a `MavenProject`, so your mojo can query project variables. + +### Using PlexusTestCase + +Mojo variables are injected by Guice (an open-source software framework for the Java platform), sometimes with a Codehaus Plexus (a collection of components used by Apache Maven) adapter. + +Both Guice-based and Plexus-based mojos rely on the Guice Plexus adapter to inject dependencies by having the test class extend `PlexusTestCase` and calling the **lookup()** method to instantiate the mojo. +Tests for fully guicified mojos can also inject dependencies directly into the constructor without extending `PlexusTestCase`. +These dependencies can be Mockito mocks or instances of the actual model classes. +If a particular test does not access the injected field — that is, it’s only injected to fulfill the constructor signature — you can usually also pass null as the value of that argument. + +With that said, if you need to inject Maven objects into your mojo, you’ll probably prefer to use the maven-plugin-testing-harness. + +### Using the maven-plugin-testing-harness + +The [maven-plugin-testing-harness](/plugin-testing/maven-plugin-testing-harness/) is designed to test the implementation of the `org.apache.maven.reporting.AbstractMavenReport#execute()` method. + +You have to include `maven-plugin-testing-harness` as a test-scoped dependency. + +```xml +... + <dependencies> + ... + <dependency> + <groupId>org.apache.maven.plugin-testing</groupId> + <artifactId>maven-plugin-testing-harness</artifactId> + <!-- use the latest version of the maven-plugin-testing-harness, >= 3.4.0 --> + <version>3.4.0</version> + <scope>test</scope> + </dependency> + ... + </dependencies> +... +``` + +#### JUnit Jupiter (JUnit 5) style tests + +JUnit Jupiter uses an extension framework for which `MojoExtension` is provided by the `maven-plugin-testing-harness`. +You can annotate your JUnit Jupiter test with `@MojoTest`; then inject the mojo under test into the test method with the `@InjectMojo` annotation. +This functionality was introduced in version `3.4.0` of the `maven-plugin-testing-harness`. +Below is an example: + +```java +@MojoTest +public class YourMojoTest { + + private static final String POM = "src/test/resources/unit/basic-test/basic-test-plugin-config.xml"; Review Comment: I'm tempted to inline this. Named constants for single use strings aren't helpful. ########## content/markdown/plugin-developers/plugin-testing.md: ########## @@ -0,0 +1,154 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Developers Centre - Testing Plugins + +## Introduction + +This document is intended to help Maven Developers test plugins with unit tests, integration tests, and functional tests. + +## Testing Styles: Unit Testing vs. Functional/Integration Testing + +A unit test attempts to verify a mojo as an isolated unit, by mocking out the rest of the Maven environment. +A mojo unit test does not attempt to run your plugin in the context of a real Maven build. Unit tests are designed to be fast. + +Functional tests run much more slowly than unit tests, but they can catch bugs or detect issues that you may not catch with unit tests. + +The general wisdom is that your code should be mostly tested with unit tests, but should also have some functional tests. + +## Unit Tests + +### Using JUnit alone + +In principle, you can write a unit test of a plugin Mojo the same way you’d write any other JUnit test case. + +However, many mojo methods need more dependencies to work properly. +For example, you’ll probably need to inject or mock a reference to a `MavenProject`, so your mojo can query project variables. + +### Using PlexusTestCase + +Mojo variables are injected by Guice (an open-source software framework for the Java platform), sometimes with a Codehaus Plexus (a collection of components used by Apache Maven) adapter. + +Both Guice-based and Plexus-based mojos rely on the Guice Plexus adapter to inject dependencies by having the test class extend `PlexusTestCase` and calling the **lookup()** method to instantiate the mojo. +Tests for fully guicified mojos can also inject dependencies directly into the constructor without extending `PlexusTestCase`. +These dependencies can be Mockito mocks or instances of the actual model classes. +If a particular test does not access the injected field — that is, it’s only injected to fulfill the constructor signature — you can usually also pass null as the value of that argument. + +With that said, if you need to inject Maven objects into your mojo, you’ll probably prefer to use the maven-plugin-testing-harness. + +### Using the maven-plugin-testing-harness + +The [maven-plugin-testing-harness](/plugin-testing/maven-plugin-testing-harness/) is designed to test the implementation of the `org.apache.maven.reporting.AbstractMavenReport#execute()` method. + +You have to include `maven-plugin-testing-harness` as a test-scoped dependency. + +```xml +... + <dependencies> + ... + <dependency> + <groupId>org.apache.maven.plugin-testing</groupId> + <artifactId>maven-plugin-testing-harness</artifactId> + <!-- use the latest version of the maven-plugin-testing-harness, >= 3.4.0 --> Review Comment: delete comment ########## content/markdown/plugin-developers/plugin-testing.md: ########## @@ -0,0 +1,154 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Developers Centre - Testing Plugins + +## Introduction + +This document is intended to help Maven Developers test plugins with unit tests, integration tests, and functional tests. + +## Testing Styles: Unit Testing vs. Functional/Integration Testing + +A unit test attempts to verify a mojo as an isolated unit, by mocking out the rest of the Maven environment. +A mojo unit test does not attempt to run your plugin in the context of a real Maven build. Unit tests are designed to be fast. + +Functional tests run much more slowly than unit tests, but they can catch bugs or detect issues that you may not catch with unit tests. + +The general wisdom is that your code should be mostly tested with unit tests, but should also have some functional tests. + +## Unit Tests + +### Using JUnit alone + +In principle, you can write a unit test of a plugin Mojo the same way you’d write any other JUnit test case. + +However, many mojo methods need more dependencies to work properly. +For example, you’ll probably need to inject or mock a reference to a `MavenProject`, so your mojo can query project variables. + +### Using PlexusTestCase + +Mojo variables are injected by Guice (an open-source software framework for the Java platform), sometimes with a Codehaus Plexus (a collection of components used by Apache Maven) adapter. + +Both Guice-based and Plexus-based mojos rely on the Guice Plexus adapter to inject dependencies by having the test class extend `PlexusTestCase` and calling the **lookup()** method to instantiate the mojo. +Tests for fully guicified mojos can also inject dependencies directly into the constructor without extending `PlexusTestCase`. +These dependencies can be Mockito mocks or instances of the actual model classes. +If a particular test does not access the injected field — that is, it’s only injected to fulfill the constructor signature — you can usually also pass null as the value of that argument. + +With that said, if you need to inject Maven objects into your mojo, you’ll probably prefer to use the maven-plugin-testing-harness. + +### Using the maven-plugin-testing-harness + +The [maven-plugin-testing-harness](/plugin-testing/maven-plugin-testing-harness/) is designed to test the implementation of the `org.apache.maven.reporting.AbstractMavenReport#execute()` method. + +You have to include `maven-plugin-testing-harness` as a test-scoped dependency. + +```xml +... + <dependencies> + ... + <dependency> + <groupId>org.apache.maven.plugin-testing</groupId> + <artifactId>maven-plugin-testing-harness</artifactId> + <!-- use the latest version of the maven-plugin-testing-harness, >= 3.4.0 --> + <version>3.4.0</version> + <scope>test</scope> + </dependency> + ... + </dependencies> +... +``` + +#### JUnit Jupiter (JUnit 5) style tests + +JUnit Jupiter uses an extension framework for which `MojoExtension` is provided by the `maven-plugin-testing-harness`. +You can annotate your JUnit Jupiter test with `@MojoTest`; then inject the mojo under test into the test method with the `@InjectMojo` annotation. +This functionality was introduced in version `3.4.0` of the `maven-plugin-testing-harness`. +Below is an example: + +```java +@MojoTest +public class YourMojoTest { + + private static final String POM = "src/test/resources/unit/basic-test/basic-test-plugin-config.xml"; + + @Test + @InjectMojo(goal = "generate", pom = POM) + void simpleMojo(YourMojo mojo) { + assertNotNull(mojo); + } +} +``` + +#### JUnit 4 style tests (deprecated) +For Maven 3 there is the deprecated way to write tests using JUnit 4 style. Review Comment: Rewrite this paragraph and don't mark it deprecated. Maybe, Maven 3 allows JUnit 4 style tests. Maven 4 only allows Junit Jupiter tests. ########## content/markdown/plugin-developers/plugin-testing.md: ########## @@ -0,0 +1,154 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Developers Centre - Testing Plugins + +## Introduction + +This document is intended to help Maven Developers test plugins with unit tests, integration tests, and functional tests. + +## Testing Styles: Unit Testing vs. Functional/Integration Testing + +A unit test attempts to verify a mojo as an isolated unit, by mocking out the rest of the Maven environment. +A mojo unit test does not attempt to run your plugin in the context of a real Maven build. Unit tests are designed to be fast. + +Functional tests run much more slowly than unit tests, but they can catch bugs or detect issues that you may not catch with unit tests. + +The general wisdom is that your code should be mostly tested with unit tests, but should also have some functional tests. + +## Unit Tests + +### Using JUnit alone + +In principle, you can write a unit test of a plugin Mojo the same way you’d write any other JUnit test case. + +However, many mojo methods need more dependencies to work properly. +For example, you’ll probably need to inject or mock a reference to a `MavenProject`, so your mojo can query project variables. + +### Using PlexusTestCase + +Mojo variables are injected by Guice (an open-source software framework for the Java platform), sometimes with a Codehaus Plexus (a collection of components used by Apache Maven) adapter. + +Both Guice-based and Plexus-based mojos rely on the Guice Plexus adapter to inject dependencies by having the test class extend `PlexusTestCase` and calling the **lookup()** method to instantiate the mojo. +Tests for fully guicified mojos can also inject dependencies directly into the constructor without extending `PlexusTestCase`. +These dependencies can be Mockito mocks or instances of the actual model classes. +If a particular test does not access the injected field — that is, it’s only injected to fulfill the constructor signature — you can usually also pass null as the value of that argument. Review Comment: delete "also" ########## content/markdown/plugin-developers/plugin-testing.md: ########## @@ -0,0 +1,154 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Developers Centre - Testing Plugins + +## Introduction + +This document is intended to help Maven Developers test plugins with unit tests, integration tests, and functional tests. + +## Testing Styles: Unit Testing vs. Functional/Integration Testing + +A unit test attempts to verify a mojo as an isolated unit, by mocking out the rest of the Maven environment. +A mojo unit test does not attempt to run your plugin in the context of a real Maven build. Unit tests are designed to be fast. + +Functional tests run much more slowly than unit tests, but they can catch bugs or detect issues that you may not catch with unit tests. + +The general wisdom is that your code should be mostly tested with unit tests, but should also have some functional tests. + +## Unit Tests + +### Using JUnit alone + +In principle, you can write a unit test of a plugin Mojo the same way you’d write any other JUnit test case. + +However, many mojo methods need more dependencies to work properly. +For example, you’ll probably need to inject or mock a reference to a `MavenProject`, so your mojo can query project variables. + +### Using PlexusTestCase + +Mojo variables are injected by Guice (an open-source software framework for the Java platform), sometimes with a Codehaus Plexus (a collection of components used by Apache Maven) adapter. + +Both Guice-based and Plexus-based mojos rely on the Guice Plexus adapter to inject dependencies by having the test class extend `PlexusTestCase` and calling the **lookup()** method to instantiate the mojo. Review Comment: delete "rely on the Guice Plexus adapter to" as Plexus mojos don't do this. ########## content/markdown/plugin-developers/plugin-testing.md: ########## @@ -0,0 +1,189 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# Developers Centre - Testing Plugins Strategies + +## Introduction + +Currently, Maven only supports unit testing out of the box. +This document is intended to help Maven Developers test plugins with unit tests, integration tests, and functional tests. + +## Testing Styles: Unit Testing vs. Functional/Integration Testing + +A unit test attempts to verify a mojo as an isolated unit, by mocking out the rest of the Maven environment. +A mojo unit test does not attempt to run your plugin in the context of a real Maven build. Unit tests are designed to be fast. + +A functional/integration test attempts to use a mojo in a real Maven build, by launching a real instance of Maven in a real project. +Normally this requires you to construct special dummy Maven projects with real POM files. +Often this requires you to have already installed your plugin into your local repository so it can be used in a real Maven build. +Functional tests run much more slowly than unit tests, but they can catch bugs that you may not catch with unit tests. + +The general wisdom is that your code should be mostly tested with unit tests, but should also have some functional tests. + +## Unit Tests + +### Using JUnit alone + +In principle, you can write a unit test of a plugin Mojo the same way you’d write any other JUnit test case. + +However, many mojo methods need more information to work properly. +For example, you’ll probably need to inject or mock a reference to a `MavenProject`, so your mojo can query project variables. + +### Using PlexusTestCase + +Mojo variables are injected by Guice (an open-source software framework for the Java platform), sometimes with a Codehaus Plexus (a collection of components used by Apache Maven) adapter to support the legacy `@Component` annotation. +Currently some mojos are fully guicified with constructor injection, while others that have not yet been converted use Plexus field injection. + +Both Guice-based and Plexus-based mojos rely on the Guice Plexus adapter to inject dependencies by having the test class extend `PlexusTestCase` and calling the **lookup()** method to instantiate the mojo. Review Comment: PlexusTestCase is in a different project and repo, so can't be deprecated here. I would like to get rid of it, but I'm not sure I can. It is overused. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
