Hi Dennis - I hadn’t thought of that - we could have a fast failsafe and then a slow one run at different times. Thanks! good idea. AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/> e: aa...@chatnbike.com <mailto:aa...@chatnbike.com> t: (301) 956-2319
> On Jan 23, 2020, at 9:58 AM, Dennis Scheffer <den...@selbstdenker.ag> wrote: > > >> Cloning a “company” EO and testing unique constraints in SQL - is heavier >> than testing an “isCamelCase()” function but lighter than selenium. Maybe we >> have to do it in failsafe but it feels closer to regular unit tests that >> should fire every time there is a checkin to the repo. In other words if >> your tests take 5 minutes to run, why not let Agnes tell you immediately >> that the build is broken rather than waiting till midnight for selenium to >> do so? > > If there are multiple ways in which you would like to use the failsafe > plugin, you can always add multiple executions and put them in their own > build profiles > (https://maven.apache.org/guides/introduction/introduction-to-profiles.html > <https://maven.apache.org/guides/introduction/introduction-to-profiles.html>). > Then you can fire failsafe every time you check in new code without selenium > and you can do something like this if your want selenium tests to be run: > 'mvn clean verify -P with-selenium'. There are a bunch of ways to configure > profiles to do something like that. > > -- > Dennis > >> On 23. Jan 2020, at 15:39, Aaron Rosenzweig <aa...@chatnbike.com >> <mailto:aa...@chatnbike.com>> wrote: >> >> Dennis that is a good point, >> >> At the moment I have not cleaned and the product is there but it’s not >> working but your point is still well taken. In Jenkins, in the cloud, it >> will do a clean and I really should be doing a clean every time so the >> product won’t be there to test with… there won’t be a bundle. >> >> Maven “Failsafe” makes sense for selenium… which is technically a JUnit test >> too but it’s very heavy and flexes the UI of a bundled and launched app. >> >> Cloning a “company” EO and testing unique constraints in SQL - is heavier >> than testing an “isCamelCase()” function but lighter than selenium. Maybe we >> have to do it in failsafe but it feels closer to regular unit tests that >> should fire every time there is a checkin to the repo. In other words if >> your tests take 5 minutes to run, why not let Agnes tell you immediately >> that the build is broken rather than waiting till midnight for selenium to >> do so? >> >> http://www.globalnerdy.com/wp-content/uploads/2008/08/you_broke_the_build.jpg >> >> <http://www.globalnerdy.com/wp-content/uploads/2008/08/you_broke_the_build.jpg> >> >> When we run from within Eclipse we have a “bundless build” that uses the >> Fluffy Bunny NSBundle variant and works great… without a product… and the >> destructive EOF unit tests work there. I think what Markus did was patch >> NSBundle to treat the maven target with the intermediate classes and >> resources as a “maven bundless build” or a “maven black-ops bunny” >> if-you-will. >> >> I’m still confused but clarity is setting in. Thank you everyone for this >> hearty discussion. >> AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/> >> e: aa...@chatnbike.com <mailto:aa...@chatnbike.com> t: (301) 956-2319 >> >> >> >>> On Jan 23, 2020, at 2:54 AM, Dennis Scheffer <den...@selbstdenker.ag >>> <mailto:den...@selbstdenker.ag>> wrote: >>> >>> Hi everyone, >>> >>> >>>> // That's the main bundle when running tests from Eclipse >>>> Path mainBundlePath = Paths.get("build/your-project.woa"); >>>> >>>> if (Files.notExists(mainBundlePath)) { >>>> // Maven doesn't create a build directory. The WOA bundle goes into the >>>> target folder instead. >>>> mainBundlePath = Paths.get("target/your-project.woa"); >>>> } >>>> >>>> ERXExtensions.initApp("your-project", mainBundlePath.toUri().toURL(), >>>> ACUnitTestingApplication.class, args); >>> >>> This may not work under certain circumstances because the surefire plugin >>> usually runs in the Maven 'test' phase which is before the 'package' phase. >>> Therefore, there may not be a bundle at 'target/your-project.woa' – >>> especially if you do a 'mvn clean test'. >>> >>> The solution is very simple: I would consider tests that depend on a >>> pre-build bundle integration tests (which makes sense because most of the >>> time all the application's 'units' are integrated in a bundle). And just >>> use the Maven failsafe pugin >>> (https://maven.apache.org/surefire/maven-failsafe-plugin/ >>> <https://maven.apache.org/surefire/maven-failsafe-plugin/>). It works >>> exactly the same as the surefire plugin but runs in the 'verify' phase >>> which is after the 'package' phase. So 'mvn clean verify' will clean your >>> target directory, create a fresh new bundle and run your tests on your >>> fresh bundle with the solution mentioned above. >>> >>> With regards, >>> -- >>> Dennis >>> >>> >>>> On 23. Jan 2020, at 02:28, Henrique Prange via Webobjects-dev >>>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >>>> wrote: >>>> >>>> Hey Aaron, >>>> >>>> This error rings a bell. I don't recall all the details. It looks like the >>>> collectMainProps method is trying to find the Properties file of your >>>> project in the wrong place. >>>> >>>> When you build your project in Eclipse with WOLips, it generates a build >>>> folder containing your project's WOA bundle. Maven, however, puts the >>>> generated WOA bundle in the target folder. I'm afraid the application >>>> initialization code keeps looking for the build folder when you run your >>>> tests with Maven. >>>> >>>> I'm not sure if there's a better way to solve this problem. Anyway, the >>>> code below may fix it. >>>> >>>> // That's the main bundle when running tests from Eclipse >>>> Path mainBundlePath = Paths.get("build/your-project.woa"); >>>> >>>> if (Files.notExists(mainBundlePath)) { >>>> // Maven doesn't create a build directory. The WOA bundle goes into the >>>> target folder instead. >>>> mainBundlePath = Paths.get("target/your-project.woa"); >>>> } >>>> >>>> ERXExtensions.initApp("your-project", mainBundlePath.toUri().toURL(), >>>> ACUnitTestingApplication.class, args); >>>> >>>> Cheers, >>>> >>>> HP >>>> >>>>> On Jan 22, 2020, at 2:09 PM, Aaron Rosenzweig via Webobjects-dev >>>>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I’m trying to run maven unit tests with the surefire plugin that make use >>>>> of EOF but it’s not working out. >>>>> >>>>> I can run them in Eclipse with a direct launch as a bundless build and it >>>>> works. I make a call in the static initializer of the test case to: >>>>> ERXExtensions.initApp(ACUnitTestingApplication.class, arguments); >>>>> >>>>> And it thinks it’s a WO app and has access to the model group and all of >>>>> EOF and I can do destructive stuff like creating and saving Eos to the DB >>>>> all inside a launch from Eclipse. >>>>> >>>>> Where I’m running into trouble is trying to do it with Maven. At the >>>>> moment I’m getting a null pointer from maven launch at the following >>>>> place. >>>>> >>>>> er.extensions.appserver.ERXApplication$Loader.collectMainProps(ERXApplication.java:757) >>>>> >>>>> I think because it is wanting to treat it as a bundle but it isn’t and >>>>> so… I’m not sure where to go from here. Any advice? >>>>> >>>>> AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/> >>>>> e: aa...@chatnbike.com <mailto:aa...@chatnbike.com> t: (301) 956-2319 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Do not post admin requests to the list. They will be ignored. >>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>>>> <mailto:Webobjects-dev@lists.apple.com>) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> https://lists.apple.com/mailman/options/webobjects-dev/hprange%40gmail.com >>>>> >>>>> <https://lists.apple.com/mailman/options/webobjects-dev/hprange%40gmail.com> >>>>> >>>>> This email sent to hpra...@gmail.com <mailto:hpra...@gmail.com> >>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>>> <mailto:Webobjects-dev@lists.apple.com>) >>>> Help/Unsubscribe/Update your Subscription: >>>> https://lists.apple.com/mailman/options/webobjects-dev/dennis%40selbstdenker.ag >>>> >>>> <https://lists.apple.com/mailman/options/webobjects-dev/dennis%40selbstdenker.ag> >>>> >>>> This email sent to den...@selbstdenker.ag <mailto:den...@selbstdenker.ag> >> >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
