Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detection of concordion tests #7

Closed
timmy-wright opened this issue Nov 2, 2015 · 8 comments
Closed

Detection of concordion tests #7

timmy-wright opened this issue Nov 2, 2015 · 8 comments

Comments

@timmy-wright
Copy link

I've got a project where I'm using both Concordion and Wicket.

For Wicket, I have HTML files named the same as the Java class. So "SystemConfigPage.java" and "SystemConfigPage.html".

The plugin is giving me an error on the wicket java page saying "Test Fixture is not annotated with @RunWith(ConcordionRunner.class). But it is not actually a concordion test.

2015-11-02 13_14_30-vips - c__users_t_timw7_projects_pceftpos_vips - presentation - _presenta

@idegtiarenko
Copy link
Member

Hello Tim.

At the moment plugin detects every java and html pair as concordion test.
I am looking for better ways of detection.

I was thinking about concordion namespace declaration in html file as indicator, but generally that is optional.
My other option is to try identify concordion only in test sources. Is there a chance html spec or test fixture may be located in production code? Like dedicated integration test modules.

Please let me know what do You think about this.

@timmy-wright
Copy link
Author

Hi,

The "test sources only" idea is a good one - all my wicket classes and html are in the src/main tree - and all my concordion code is in src/test tree. I've never seen any concordion specs in src/main. However, Nigel Charman has seen more concordion than me, so I'll direct him here for a comment.

@nigelcharman
Copy link
Member

I don't think we should rely on the spec and fixture being only in test sources. While this is certainly the normal case, I'm pretty sure there's some edge cases out there. If you do go for this approach, I'd suggest a configuration option to override.

Better might be to check whether the HTML contains the string http://www.concordion.org/2007/concordion. This should give a fairly safe indicator. If you wanted to be more precise you could go the extra step of checking if any element has an attribute with the http://www.concordion.org/2007/concordion namespace.

@talios
Copy link

talios commented Nov 4, 2015

@nigelcharman +2. I'm looking at writing an asciidoctor concordion extension actually, and altho the HTML might be an external file may not always be ( still considering how I want to handle the blending at the moment). But even then, the correlation between HTML and class might not be a one to one.

I know if our own current concordion tests at work, there's not a one to one mapping, tho I'm tempted to change that just for making things easier to reason about.

@timmy-wright
Copy link
Author

Hi all,

Just to put this in context, this is for an intellj concordion plugin - to link the HTML spec and the Java fixture. I currently have an issue that if you use the plugin in a project using Apache Wicket, the plugin detects the wicket pages as Concordion fixtures and errors start appearing in lots of places as the plugin says "you forgot to say @RunWith(ConcordionRunner.class)".

My view is the 80/20 rule. As everyone's concordion fixtures and specs are in the test src root (and never in the main src root), it'd be nice to solve the current problem and then wait to see if anyone who has concordion tests in the main root complain (which seems to be a far edge case)

Note that this won't impact how concordion itself runs the tests. It just impacts how the plugin links specs and html files for analysis.

(btw: the plugin is awesome)

@nigelcharman
Copy link
Member

Common patterns I do see are:

  • Tests and Specs in the same folder (often src/test/java)
  • Additional source sets being used for specs (eg. src/spec/resources and src/spec/java), with the source set then used by test tasks in Gradle (which should be detected as a test source in IDEA)

Happy to go with Tim's suggestion if we make it clear in the README that the fixtures and specs must be in a test source.

Note that specs can also be .xls files at the moment (with the Excel extension) and .md (with the soon to be released Markdown extension).

FYI - In future, I'd love to support having multiple fixtures to allow a single spec to be re-used for testing at different layers of the SUT, similar to the Behat's test suites. But not worth considering that at the moment.

@idegtiarenko
Copy link
Member

Thanks for Your feedback.

At the moment I am thinking about considering java and html pair as concordion if html have concordion namespace OR java have concordion runner. Hope this will work fine.

I do not have support of excel or markdown right now, but I hope to start working on that soon.

idegtiarenko added a commit that referenced this issue Nov 5, 2015
@nigelcharman
Copy link
Member

Let us know if you need the extensions to include some metadata to define the file extensions that they support.

On 5 November 2015 3:59:13 PM NZDT, Ievgen Degtiarenko notifications@github.com wrote:

Thanks for Your feedback.

At the moment I am thinking about considering java and html pair as
concordion if html have concordion namespace OR java have concordion
runner. Hope this will work fine.

I do not have support of excel or markdown right now, but I hope to
start working on that soon.


Reply to this email directly or view it on GitHub:
#7 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants