incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juan Pablo Santos Rodríguez <juanpablo.san...@gmail.com>
Subject Re: Latest update notes...
Date Wed, 03 Jul 2013 18:05:35 GMT
Hi Glen,

regarding 3, yes, filtering is done in the main branch of IT tests,
although it doesn't use filter.properties at all:
- jspwiki-selenium-tests/src/main/resources contains a bare, unfiltered
./WEB-INF/jspwiki.properties
- each pom.xml of every jspwiki-it-* module under jspwiki-it-tests contains
several properties which are used to "populate" a different
jspwiki.properties file.
- when the integration-tests profile is used,
   + every IT module uses jspwiki-war as a maven overlay (i.e.: is unzipped
and used as a base war structure),
   + then the resources of each module are processed. This means
jspwiki-selenium-tests/src/main/resources/WEB-INF/jspwiki.properties gets
filtering applied with the specific properties of each module so finally,
   + as it is defined as a maven resource of a war module, it get's copied
to WEB-INF/jspwiki.properties of the war used for IT testing, under
./target of each module, effectively overwritting the original
jspwiki.properties from jspwiki-war

as for IT execution: right now is locale-dependant, I haven't found a way
to enforce default locale no tomcat7-plugin yet, that's why JSPWIKI-770
isn't marked as resolved. Probably the fastest way is to add a new test
which set user locale to english, but hadn't had the time.

Also, IT executions uses google chrome as the default test browser, as
tests execution is faster than firefox, and way faster than IE10. Other
than that, they should run fine. Maybe there's a failure here or there b/c
selenium scripts haven't been kept up to date with trunk, but they should
be mostly ok.


br,
juan pablo

On Wed, Jul 3, 2013 at 5:54 PM, Glen Mazza <glen.mazza@gmail.com> wrote:

> Hi Team, some notes:
>
> 1.) I updated to JDOM2 (the older JDOM branch was retired) -- the tests
> are now all passing (except integration tests, see last comment).  The
> earlier problem I had brought up was solved via an override to one of JDOMs
> classes:
>
> http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/**
> jspwiki-war/src/main/java/org/**apache/wiki/render/**
> CustomXMLOutputProcessor.java?**view=markup<http://svn.apache.org/viewvc/incubator/jspwiki/trunk/jspwiki-war/src/main/java/org/apache/wiki/render/CustomXMLOutputProcessor.java?view=markup>
>
> Otherwise, mainly a bunch of org.jdom -> org.jdom2 package renaming.
>
> 2.) I updated from JUnit 3.8.2 to the latest JUnit 4.11, with that version
> we now have the ability to test single test methods within a test case:
>
> mvn test -Dtest=**JSPWikiMarkupParserTest#**testHeadingHyperlinks3 (just
> that single test)
> or
> mvn test -Dtest=JSPWikiMarkupParserTest (all tests in that class)
>
> I add notes about this to http://svn.apache.org/viewvc/**
> incubator/jspwiki/trunk/mvn_**cheat-sheet.txt?view=markup<http://svn.apache.org/viewvc/incubator/jspwiki/trunk/mvn_cheat-sheet.txt?view=markup>
> Also, I added links in the above cheat sheet on how to debug/trace test
> cases in Eclipse and IDEA -- it's pretty simple to do.
>
>
> 3.) I moved the src/main/filters/filters.txt to
> src/test/filters/filters.txt as up to now all filtering was being done on
> test resources.
>
> However, maybe (?) resource filtering is being done in the main branch for
> the integration tests?  JP -- is line #66 below necessary?
> http://svn.apache.org/viewvc/**incubator/jspwiki/trunk/**
> jspwiki-it-tests/pom.xml?**revision=1487137&view=markup#**l64<http://svn.apache.org/viewvc/incubator/jspwiki/trunk/jspwiki-it-tests/pom.xml?revision=1487137&view=markup#l64>
>
>
> 4.) For me, the integration tests are failing left and right (even before
> this change), I don't know if it's something I did in a recent commit
> (prior to the change to JDOM2, same errors were occurring for me), or if
> it's just my machine.  I'll look into this next but if JP or someone else
> can immediately spot (or at least confirm) the error it would be
> appreciated.
>
> Thanks,
> Glen
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message