+ 1, as always I am supportive to have these specialized tests run as an optional tests and by the developers who have vested interested in making sure they are not broken.
Suresh On Apr 1, 2014, at 2:52 PM, Lahiru Gunathilake <[email protected]> wrote: > Hi Devs, > > I am thinking of changing the build as below in regards to Grid related Unit > Tests. This mail is not about integration tests. > > Normal users who does not have grid credentials will invoke the default > profile and it will builds all the required modules with non-grid Testcases. > To identify the test cases to skip, throughout all the modules I am thinking > of putting a simple filter like all the classes ends with > TestWithMyProxyAuth.java,TestWithEC2Auth.java, TestWithSSHAuth.java. As an > example if I want to write a test to check AdvancedInputHandler I write a > test class like AdvancedInputHandlerTestWithMyProxyAuth.java. If these names > are too big we can remove the Auth part, so it looks like > AdvancedInputHandlerTestWithMyProxy.java. > > And importantly you might have requirement of changing the surefire-plugin > inside your module, in that case you have to add surefire plugin in to your > plugin list but please make sure that you inherit airavata-parent pom > surefire-plugin configuration by putting <inherited>true</inherited>, so we > are not missing parent-pom configuration in your module. > > If someone wants to run (mostly the developers who have grid credentials, or > ec2 credentials, or ssh credentials) we are having different profiles, so the > build will run like below. > > step 1: mvn clean install - bulid only the non-grid related tests adn build > all the modules > step 2: mvn clean install -PgridTests - step 1 + **/*TestWithMyProxyAuth.java > step 3: mvn clean install -PsshTests - step 1 + **/*TestWithSSHAuth.java > step 4: mvn clean install -Pec2Tests - step 1 + **/*TestWithEC2Auth.java > step 5: mvn clean install -PallGridTest - step 2 + step 3 - This will run all > the Grid related tests except EC2 > > With this approach any module can have tests to run with our supporting > resource types, ex: orchestrator can have grid tests, ec2 tests, and bigred2 > tests. > WDYT ? > > Regards > Lahiru > > > > > On Thu, Mar 27, 2014 at 11:28 AM, Raminder Singh <[email protected]> > wrote: > +1 to have separate profiles for testing. > > Raminder > > On Mar 27, 2014, at 11:25 AM, Lahiru Gunathilake <[email protected]> wrote: > >> Yes I was thinking of having different build profiles and in the default >> profile we remove the grid/ec2 related tests. >> So for a release we have to run the release profile which includes >> everything. >> Regards >> Lahiru >> >> >> On Thu, Mar 27, 2014 at 11:17 AM, Marlon Pierce <[email protected]> wrote: >> How about having an "all tests" profile for full release testing? >> >> >> Marlon >> >> On 3/27/14 11:11 AM, Suresh Marru wrote: >> > Also, same could be argued for other providers like EC2, Unicore and so on. >> > >> > I mean you want to have Unicore to european clusters a test case and if a >> > XSEDE developer does not have those credentials, those tests should be in >> > separate silos as well. >> > >> > Suresh >> > >> > On Mar 27, 2014, at 11:09 AM, Suresh Marru <[email protected]> wrote: >> > >> >> + 1, I like this tradeoff. >> >> >> >> Suresh >> >> >> >> On Mar 27, 2014, at 11:07 AM, Lahiru Gunathilake <[email protected]> >> >> wrote: >> >> >> >>> Hi All, >> >>> >> >>> Currently in Airavata trunk we have disabled all the tests with grid >> >>> security, main reason is normal user who comes to airavata might not >> >>> have any grid security to build airavata with tests. >> >>> >> >>> I think we have to separate out grid related tests and run them separate >> >>> from a normal build and write more test cases to test the local >> >>> functionality for each modules to test each functionality and enable >> >>> tests to build in airavata. Test cases which should need grid security >> >>> has to go to grid related test module which is not part of the main >> >>> build. >> >>> >> >>> Grid security related tests cases are really important for us to test >> >>> the real usecases during the development, so the developers who got >> >>> credentials can run those tests during development and others will not >> >>> be burdened of those tests but still they can build with the test-cases. >> >>> >> >>> WDYT ? >> >>> >> >>> Regards >> >>> Lahiru >> >>> >> >>> -- >> >>> System Analyst Programmer >> >>> PTI Lab >> >>> Indiana University >> >> >> >> >> -- >> System Analyst Programmer >> PTI Lab >> Indiana University > > > > > -- > System Analyst Programmer > PTI Lab > Indiana University
