-
Notifications
You must be signed in to change notification settings - Fork 9
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
Comments
Hello Tim. At the moment plugin detects every java and html pair as concordion test. I was thinking about concordion namespace declaration in html file as indicator, but generally that is optional. Please let me know what do You think about this. |
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. |
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 |
@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. |
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) |
Common patterns I do see are:
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. |
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. |
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:
|
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.
The text was updated successfully, but these errors were encountered: