scenarioo / pizza-delivery

Simple Demo using Scenarioo in Java JUnit Selenium Tests

Scenarioo

Automated Documentation of Applications with UI Tests

Scenarioo is a tool to leverage the power of your UI tests and to make them available as a documentation of your software system to all people involved in the design, development, test, operation and management of your software system.

Webpage & Documentation

For more information about Scenarioo, see the following resources:

• Webpage: http://www.scenarioo.org
• Scenarioo Documentation for Latest Official Release: http://www.scenarioo.org/docs/master
• Scenarioo Documentation for Contributors (unreleased version): http://www.scenarioo.org/docs/develop

Live Demo

You can see an example Scenarioo documentation and the Scenarioo Viewer Web App in action in our demo:

http://demo.scenarioo.org

Downloads & Links

Downloads and more links, even for different releases (like forthcoming release candidates) can be found under Downloads & Links

CI/CD Build Server

https://circleci.com/gh/scenarioo

Master: Latest Stable Release

Develop: Current Development State

License

Scenarioo is mainly distributed under GNU General Public License, which enables you to use the tool freely.

The Writer Libraries use GNU license with linking exception, for freely linking it even in your commercial products (if needed at all).

Most examples are provided using BSD license, which even allows you to copy these code examples freely.

See LICENSE.txt and further LICENSE-files for different licenses of different components in some subproject folders and especially in our separate library and example repositories, hosted under https://github.com/scenarioo

pizza-delivery's Issues

Windows Setup section in README

This section was added by @danielsuter and explains how the Scenarioo Viewer can be set up on Windows. I think this does not belong into the example but should be integrated into the general setup instructions of Scenarioo.

@bruderol @danielsuter What's your opinion on this?

PS: The last three lines are about running the example tests. I moved this to the top of the readme in branch https://github.com/scenarioo/pizza-delivery/tree/rename-pizza-shop-folder.

Use Scenarioo from Maven Central and Update Dependencies

• Use official Scenarioo release from Maven Central
• Update JUnit 4 to latest version
• Improve example Metadata in gradle.build (org.scenarioo as groupId)

I do this right now.

Migrate Pizza Sample to JUnit 5

sitting at Devoxx talk by the JUnit guys about Junit I realize it might be important to have a junit 5 example for Scenarioo soon.

With junit5 integration of scenarioo should be even more elegant.

@ideco and @adiherzog what do you think?

Change the default branch to master and leave only pizza-shop in gh-pages

Since now we have a master branch, it should also be the main branch of this project. Then we can remove the test code from gh-pages and move the pizza-shop to the root folder.

Also, the links in the read-me should be adapted.

Improve Scenarioo Reporter

Some findings from junit5 refactoring to be addressed in both versions (junit4 and junit5) of the example:

1. Exception information (stacktrace) should be attached to scenarioo report on test failure.

2. WebDriver is initialized to listen for all interactions for each use case - shouldnt the listener only start to report during test execution (such that a test could do some test preparation without reporting it?)? Currenty it looks a bit weird this initialization is only done once per test class. In junit5 there is a special hook for BeforeTestExecution that could be used for that.

   • also this kind of opening the browser for each use case leads to browser poping always up again during test execution on desktop for many tests (maybe we should reuse the browser somehow)

3. ScenariooEventListener: better rename to ScenariooStepReporter or even WebDriverStepReporter?

4. UseCaseContext:

   • I think we should rename this to "ScenriooReporterContext" or something similar, since it holds more than just the use case
   • Ideas for junit5 only:
     • maybe it would be better to not handle that as a Singleton through the context holder but directly hold it inside the reporter ??
     • also we should later change it to use more of the JUnit 5 context info - see class ExtensionContext (e.g. DisplayName!)

5. Further Ideas for Junit 5 only:

   • support Tag annotation from junit5

Maybe use the ClasspathSuite to write build.xml after running all tests

See: https://github.com/takari/takari-cpsuite

This would allow to fix the overall status problem described here: https://github.com/scenarioo/pizza-delivery/blob/gh-pages/test/src/test/java/org/scenarioo/pizza/webtests/BranchAndBuildFileWriterTest.java

Another alternative would be to write branch.xml and build.xml in the gradle script in the test target.

Jenkins Build: Automatic deployment of app under test to github pages

Introduce a simple step in the build pipeline to publish current verison of the application under test on github page of the repo

Acceptance criterias

• Cureent version of appication under test on master branch is automatically published to our github page under http://scenarioo.org/pizza-delivery
• The links on the README page are adjusted accordingly

** Implementation details**

• move application under test from prod to src/main/resources/app or something similar (more realistic compared to a real project, also by default picked up as resource directory by gradle?)
• In Jenkins pipeline: Everytime this directory has changes deploy its content to gh-pages branch (into root dir) - by commit and pushing on github (using technical scenarioo-ci user)
• Adjust README to directly link to root of github pages for seing the app under test

Prepare Example for Scenarioo 4.0

The README.md contains instructions that will be wrong with 4.0

• differnet location of config.xml!
• wrong version number!

Caution: this can only be done after the release!

Jenkins Pipeline: clean up deployed examples for removed feature branches

Setup a cleanup script similar to scenarioo pipeline to cleanup example data from old feature branches, and also cleanup too much old builds for each branch.

Also ensure to deploy only master example to master demo and other examples to develop demo.

Jenkins Build: Make it work for feature branches and pull requests

Accpetance criterias

• If a featurer branch is opened like feature/{issueNumber}-{description} and a pull request is opened for such a branch and some changes are pushed to it , then the build will run and report success or failure of verifying it properly to the Pull Request on Github
• verify this works for a failing test
• verify this works for a succesful build