From version 130.1
edited by Vincent Massol
on 2018/11/25 10:59
To version 131.1
edited by Vincent Massol
on 2018/11/25 11:02
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -10,7 +10,7 @@
10 10  
11 11  * Code committed must have associated automated tests. There's [[a check in the build>>Community.Building||anchor="HAutomaticChecks"]] (in the ##quality## profile) to ensure that committed code do not reduce the total test coverage for that module. The CI runs the ##quality## profile for each commit and fails the build if the test coverage is reduced.
12 12  ** In addition we also check for Test quality by computing Mutation Testing scores for all tests and fail the build if the global quality in a given module is reduced by a new commit (this is checked by some CI jobs every day).
13 -* Developers run unit and integration tests on their machines daily and frequently.
13 +* Developers run unit and functional tests on their machines daily and frequently.
14 14  * Functional tests are executed by the CI, at each commit.
15 15  * Performance tests are executed manually several times per year (usually for LTS releases and sometimes for stable releases too).
16 16  * Most automated functional tests are currently running in a single environment (HSQLDB/Jetty/Firefox). However, we've started to use Docked-based testing to test automatically using several configurations and are migrating more and more tests to that. There are jobs in XWiki's CI that execute tests in all configurations regularly (not at each commit though but as much as possible).
... ... @@ -31,78 +31,6 @@
31 31  * In development mode, you can start the test runner process by running {{code}}mvn jasmine:bdd{{/code}} in your command line. This will start a test runner at ##http:~/~/localhost:8234##, that will run all tests in the ##src/test/javascript## directory. Write your tests there and hit refresh to see the results directly in your browser.
32 32  * For tests that need a DOM, see [[Functional Testing>>||anchor="HFunctionalTesting"]]
33 33  
34 -= Integration Testing =
35 -
36 -An integration test tests several classes together but without a running XWiki instance. For example if you have one Component which has dependencies on other Components and they are tested together this is called Integration testing.
37 -
38 -== Java Integration Testing ==
39 -
40 -* These tests are written using JUnit 5.x and [[Mockito>>https://code.google.com/p/mockito/]] (we were using [[JMock 2.x>>http://jmock.org/]] before and still have a lot of tests not converted to Mockito yet).
41 -* Your Maven module must depend on the ##xwiki-commons-test## module.
42 -* Use the ##MockitoComponentMockingRule## Rule (its javadoc explains how to use it in details).
43 -* Examples:
44 -** {{scm project="xwiki-rendering" path="xwiki-rendering-transformations/xwiki-rendering-transformation-macro/src/test/java/org/xwiki/rendering/internal/macro/DefaultMacroManagerTest.java"}}example2{{/scm}}
45 -** Other example:(((
46 -{{code language="java"}}
47 [email protected]({
48 - DefaultExtensionLicenseManager.class
49 -})
50 -public class DefaultExtensionLicenseManagerTest
51 -{
52 - @Rule
53 - public final ComponentManagerRule componentManager = new ComponentManagerRule();
54 -...
55 - @Before
56 - public void setUp() throws Exception
57 - {
58 - this.licenseManager = this.componentManager.getInstance(ExtensionLicenseManager.class);
59 - }
60 -...
61 -{{/code}}
62 -)))
63 -** Another example (using the new ##@BeforeComponent## annotation):(((
64 -{{code language="java"}}
65 [email protected]({
66 - DefaultExtensionManagerConfiguration.class,
67 - DefaultLoggerManager.class,
68 - DefaultObservationManager.class
69 -})
70 -public class DefaultExtensionManagerConfigurationTest
71 -{
72 - @Rule
73 - public final MockitoComponentManagerRule componentManager = new MockitoComponentManagerRule();
74 -
75 - private ExtensionManagerConfiguration configuration;
76 -
77 - private MemoryConfigurationSource source;
78 -
79 - @BeforeComponent
80 - public void registerComponents() throws Exception
81 - {
82 - // Register a Mocked Environment since we need to provide one.
83 - this.componentManager.registerMockComponent(Environment.class);
84 -
85 - // Register some in-memory Configuration Source for the test
86 - this.source = this.componentManager.registerMemoryConfigurationSource();
87 - }
88 -
89 - @Before
90 - public void setUp() throws Exception
91 - {
92 - this.configuration = this.componentManager.getInstance(ExtensionManagerConfiguration.class);
93 - }
94 -...
95 -{{/code}}
96 -
97 -##@BeforeComponent## is used by ##ComponentManagerRule## and methods annotated with it are called before other components are registered (i.e. before processing of ##@AllComponents## and ##@ComponentList## annotations).
98 -
99 -##MockitoComponentManagerRule## extends ##ComponentManagerRule## and just adds some helper methods to register a mock component.
100 -)))
101 -
102 -=== Best practices ===
103 -
104 -* Same as for [[unit testing>>||anchor="HJavaUnitTesting"]]
105 -
106 106  == Java Rendering Testing ==
107 107  
108 108  We have a special framework for making it easy to write Rendering tests, see the [[Rendering Testing Framework>>rendering:Main.Extending||anchor="HAddingTests"]]
... ... @@ -109,7 +109,7 @@
109 109  
110 110  == XAR Testing ==
111 111  
112 -{{info}}Since XWiki 7.3M1{{/info}} It's now possible to write integration tests for wiki pages on the filesystem (in XML format).
40 +{{info}}Since XWiki 7.3M1{{/info}} It's now possible to write unit tests for wiki pages on the filesystem (in XML format).
113 113  {{info}}Since XWiki 10.5RC1{{/info}} Tests extending ##PageTest## must now using JUnit5.
114 114  
115 115  The way those tests work is that the XML file representing the wiki pages are loaded from the filesystem into XWikiDocument instances and a stubbed environment is defined so that XWikiDocument can then ben rendered in the desired syntax.

Get Connected