Autogenerate tests with XPEDITE
Creating mock data for unit testing is very tedious, so XPEDITE allows you to create test files with data that comes directly from items you've created in the CMS.
What is CMS first TDD?
The recommended way to work with XPEDITE is to use the CMS as a form of documentation. By having content pages that demonstrate how a component can be configured and show how it looks in a variety of different states you make a content editor's life simpler. With automated test generation the developer's life will also be improved as they will be able to use this test data to write unit tests against. With these tests in place they can edit the generated components until they pass.
As you can see below, XPEDITE comes with a documentation section installed by default. Teams are recommended to create their content variations early on based on the requirements and designs and keep these pages up to date if new variations are added.
The example above only has one variation setup up, but you may choose to configure variations that have different settings or different content.
In the future these pages become invaluable when adding new people to the team whether they be developers or content editors.
But most importantly, we can now use this data to create unit test files!
What is generated?
At present two test files are created for each component. One for valid state, and one for when it is empty. The empty test is useful to ensure that you haven't got any exceptions that occur on null or undefined objects. The valid tests need a bit more effort. The test data will be automatically created, but you will need to add in your assertions based on your requirements.
The example below shows how the test content may look for a simple page which contains a single rich text block.
A snapshot test will be automatically added based on the test data; this test stores the markup generated by the component to compare against the next time the test is run. This is useful to spot when regression issues have occurred.
The second test is a prompt to put in your specific assertions and will fail the first time you run it unless you change it.
With the tests in place, it is then time to update the generated components with all the logic and markup changes that are required until they pass.
