Re: Maven Unit tests with EOF
Re: Maven Unit tests with EOF
- Subject: Re: Maven Unit tests with EOF
- From: Aaron Rosenzweig via Webobjects-dev <email@hidden>
- Date: Thu, 23 Jan 2020 10:03:29 -0500
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: email@hidden <mailto:email@hidden> t: (301) 956-2319
> On Jan 23, 2020, at 9:58 AM, Dennis Scheffer <email@hidden> 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 <email@hidden
>> <mailto:email@hidden>> 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: email@hidden <mailto:email@hidden> t: (301) 956-2319
>>
>>
>>
>>> On Jan 23, 2020, at 2:54 AM, Dennis Scheffer <email@hidden
>>> <mailto:email@hidden>> 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
>>>> <email@hidden <mailto:email@hidden>>
>>>> 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
>>>>> <email@hidden <mailto:email@hidden>>
>>>>> 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: email@hidden <mailto:email@hidden> t: (301) 956-2319
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Webobjects-dev mailing list (email@hidden
>>>>> <mailto:email@hidden>)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>
>>>>>
>>>>> This email sent to email@hidden <mailto:email@hidden>
>>>>
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Webobjects-dev mailing list (email@hidden
>>>> <mailto:email@hidden>)
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>>
>>>> This email sent to email@hidden <mailto:email@hidden>
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden