add tests for the struts2-jquery-plugin tags

[sdutry]

Seeing that it's usualy difficult and time-consuming to test every single tag in isolation, I thought it might be a good idea to have some integration-tests for the tags.

This way, it should be easier to detect problems when they occur.

I've made a small POC for a simple case, illustrating that it's possible.
struts2-jquery-tests
Edit:

• this assumes to have struts2-jquery version 4.0.2-SNAPSHOT installed
• to run use: mvn verify

The eventual idea would be to:

• have a seperate module in the project which runs the integration tests
• have tests for each tag
• have tests for each functionality of the tags

If there's problems you can think off now for this approach, please let me know.

Please let me know your thoughts on this, so that i know if i should put effort in it or not.

[lukaszlenart]

Did you try to run this with Travis-CI?

[sdutry]

@lukaszlenart
No i did not.

What happens here when running the mvn verify is the following:

• local jetty-server is started
• tests use the platform independent HtmlUnitDriver to call the Urls and perform the tests
• local jetty-server is stopped

I currently have no experience with Travis-CI.
Could you please:

• name the big steps that happen
• point me towards the documentation
• point me toward a project which i could use as an example?

I also have no idea what the build server is that this project uses.

[sdutry]

@lukaszlenart
I managed to get this POC project onto Travis-CI.
see: struts2-jquery-tests

[lukaszlenart]

Cool, it passes so it's a way to go 💯

[sdutry]

@lukaszlenart
If i understand correctly, you're suggesting the following:

• adding the tests as a module
• adding the project to Travis-CI so it runs with every commit / pull-request

Am I correct in assuming that only someone with admin rights can add the project to Travis-CI?
(which means I'll probably have to contact @jogep for this)

Thx in advance for the info.

[lukaszlenart]

Yes and yes, only repo owner can setup build on TravisCI but that's easy :)

[sdutry]

links to work in progress:

• git branch
• Travis-CI

[lukaszlenart]

Did you open a PR? Could you add Travis badge?

[![Build Status](https://travis-ci.org/sdutry/struts2-jquery.svg?branch=issue90)](https://travis-ci.org/sdutry/struts2-jquery)

[sdutry]

@lukaszlenart
I didn't open a pull request yet.
(was going to add more tests with more tags first)

From the information i can find about the Travis badge, i conclude the following:

• should be added to the README.md
• should be done with the actual url (and not the one from my fork, since that would be wrong once it's merged)

[lukaszlenart]

I think starting even with one test is a good idea, tests for other tags can be added step-by-step with additional PRs :)

Regarding the badge: right, I was too eager :)

[sdutry]

@lukaszlenart
Ok,

I will just add the last test i wanted to add for the sj:a tag and make a pull request after that.

Thx for the advice so far concerning Travis-CI.

[jogep]

I setup travis for the struts2 jquery plugin:
https://travis-ci.org/struts-community-plugins/struts2-jquery

Is there anything I need to care about it?

[sdutry]

@jogep
i noticed and added the badge to the README.md file (in the pull request) so it shows the build status on on the github pages.

Now we should easily spot when a pull request or commit is made that breaks the build.

• all checks have passed for a pull request => referencing the exact build for the pull request on Travis-CI
• the status icon on the master branch inside the README.md

[jogep]

@sdutry Only problem what I can see that we currently not developing against master branch. Usually I create for each new release a new branch which is merged into master when the release is finished. Maybe we need to change the process here.

[sdutry]

@jogep
What i could do is to change the status badge to monitor the release/4.0.2 branch and add an indication in the README.md that it's for that branch (so we don't forget or can add more status badges the further we get).

[sdutry]

@jogep
I've switched the badge to monitor release/4.0.2
see: branch

thx for pointing this out.

[jogep]

Great can we merge this in latest release/4.0.3 branch?

[sdutry]

@jogep
I'll check to make a pull request to that branch.

Give me a minute to figure out what exactly needs to be done.

[sdutry]

@jogep
Is it possible that the version in the pom on the branch release/4.0.3 still needs to be updated to 4.0.3-SNAPSHOT ?

[sdutry]

checklist for tags to add tests for

• sj:a
• sj:div
• sj:submit
• sj:checkboxlist
• sj:radio
• sj:select
• sj:accordion (+ sj:accordionItem)
• sj:autocompleter
• sj:dialog
• sj:menu (+ sj:menuItem)
• sj:progressbar
• sj:slider (if i find a way to test it) (currently not possible with basic htmlunit-driver)
• sj:spinner (if i find a way to test it)
• sj:tabbedpanel (+ sj:tab)
• sjg:grid
• sjdt:datatables
• sjt:tree (+ sjt:treeItem)

all these checkboxes currently are things for which i should be able to find a way to test.

If there's more suggestions or ideas for tests, just post a comment below.

[sdutry]

@lukaszlenart @jogep

My initial setup for these tests did not have support for drag-and-drop features (like dragging a slider).
(arbitrary mouse movement is not supported by htmlunit-driver)

Initial setup:

• selenium
• htmlunit-driver

My workaround for this was to use the PhantomJSDriver (instead of the htmlunit-driver) for this specific test. (see SliderTagIT.java )

This however has some implications

• it requires the user to have phantomjs installed in order to be able to run the tests, or install ( mvn install) the project.
• Travis-CI has phantomjs installed by default (so this did not pose a problem)

So i was wondering the following:

• is it a good idea to add this test to the project?
• should there be a readme.MD added to explain the requirement?
• should there be a seperate profile added to the pom to perform the tests only for a certain profile?
• If this is used, should i adjust the other tests to use the PhantomJSDriver instead? (which would allow me to remove the html-unit dependency from the pom)

I would appreciate your input for this.

[jogep]

@sdutry I like the idea of seperate profile for this tests. Can this profile be chosen as default for Travis-CI?

[sdutry]

@jogep
Should be easy enough to run the command with a profile.

required steps:

• Add profile to pom.
• Move running of tests to this profile.
• Make sure they don't run when this profile isn't being used.

What i was wondering was the following:

• Should i switch all tests to only run for this profile?
• Should i switch all tests to use PhantomJSDriver?
• Should i still allow tests that should work without additional requirement to run while not being on this specific profile?

[sdutry]

Looking further into this i'll try to set it up with the Category annotation to be able to filter them.

[sdutry]

@jogep @lukaszlenart
I've made a pull request ( #112 ) which splits up the tests in to tests run by default with HtmlUnitDriver and tests run only with the profile phantomjs.

I also added categories to the tests in order to distinguish which test to run when.
This should also make it easy when someone decides to add a driver from an actual browser to the tests.

• phantomjs tests were needed in order to perform drag-and-drop with a mouse
• phantomjs can not handle alerts

I've added the both of you as reviewers to this pull request.

In case of any of the list below, please add a comment (here or in the pull request) and i'll see what can be done:

• in case you have questions
• in case you have remarks
• in case you do not agree with this setup
• in case you have ideas for improvements

Thanks in advance.

[lukaszlenart]

(sorry but I was off for few days)

The idea with a dedicated profile just for phantomjs is very good, you can use ${env.TRAVIS} to activate it when build is running on TravisCI, just a hint, the current approach also works :)

[aleksandr-m]

@sdutry Have you seen this https://github.com/klieber/phantomjs-maven-plugin ?

[sdutry]

@aleksandr-m
I am aware of the existense of the plugin.

I did not find a way to have it working independent of the environment you're on (yet).
The main issues being:

• no admin rights environments
  • will it be able to place the required files
  • Travis-ci environment has no admin rights, but has phantomjs installed by default
• phantomjs.binary.path
  • what if the person already has phantomjs installed on a different location
• executing both PhantomJsDriver tests and HtmlUnitDriver tests in a single command
  • not all tests can be run with phantomjs
  • not all tests can be run with htmlunit

Should you have an example of a working setup feel free to show me.

Feel free to make a pull request with the adjusted setup.
Just be sure to also update the .travis.yml accordingly

If you want to play with it on a personal fork (and possibly branch inside the fork) first, all you need to do is enable the forked repository on travis and it will run the tests for you on each commit (pushed to github).

[sdutry]

replaced open parts of the issue with #155 and #156