Hi Dan

Another question on integration testing.  On the feature file I have added 
fixtures to be installed as shown below,

@TopUpCardDetailsServiceFixture
@CardProductInstanceFixture
@ProductFixture
Feature: List and Create New Top-Ups

Does the fixture get installed on every scenario test case or just once for the 
feature file.

Also is there a way to tear down the fixture after it has run all test cases.

Thanks 
Dharmesh

-----Original Message-----
From: Prasad [mailto:[email protected]] 
Sent: Monday, March 03, 2014 4:22 PM
To: [email protected]
Subject: Re: Integration testing

Hi Dan,

Yes, your explanation helps on understanding the framework. 

Let me collate things related and come back to you further

Kind Regards,
Prasad.

> On Mar 3, 2014, at 15:49, Dan Haywood <[email protected]> wrote:
> 
> Hi Prasad,
> 
> The proxy wrapper is created using cglib, which works by creating
> (in-memory) a subclass of the proxied class (ie your repository class, 
> in this case), and then instantiating it.
> 
> Any methods that are final cannot be overridden, so cannot be proxied.
> 
> Not sure if that helps you (or me) understand what is going on here 
> exactly; but that's how it works.
> 
> If you can share some more of your setup code, perhaps we can unravel 
> this together?
> 
> Thx
> Dan
> 
> 
> 
> 
>> On 3 March 2014 15:40, Prasad <[email protected]> wrote:
>> 
>> Hi Dan,
>> 
>> I am working on same project with Dharmesh.
>> 
>> Regarding point number 1,
>> 
>> I have removed the "final" from the method signature to make the code 
>> set working(as quick workaround)
>> 
>> I am glad to know what impact Isis testing framework brings when we 
>> add final in method signature
>> 
>> Kind Regards,
>> Prasad.
>> 
>>>> On Mar 3, 2014, at 15:24, Dan Haywood 
>>>> <[email protected]>
>>> wrote:
>>> 
>>> ah well, so long as it's all now working for you, let's leave it at that.
>>> 
>>> Dan
>>> 
>>> 
>>>> On 3 March 2014 15:22, Chohan, Dharmesh <[email protected]>
>> wrote:
>>>> 
>>>> Hi Dan
>>>> 
>>>> 1. I am not sure what has changed apart from the method is now 
>>>> defined
>> as,
>>>> public List<Card> listAll() {
>>>>       return container.allInstances(Card.class);
>>>>   }
>>>> 
>>>> 2. The problem is fixed, I only see single statement in console output.
>>>> 
>>>> Regards
>>>> Dharmesh
>>>> 
>>>> -----Original Message-----
>>>> From: Dan Haywood [mailto:[email protected]]
>>>> Sent: Monday, March 03, 2014 12:26 PM
>>>> To: users
>>>> Subject: Re: Integration testing
>>>> 
>>>>> On 3 March 2014 12:09, Chohan, Dharmesh <[email protected]>
>> wrote:
>>>>> 
>>>>> Hi Dan
>>>>> 
>>>>> 1. The issue has been solved, there was a change in the file.
>>>> 
>>>> I'm keen to know a bit more about your fix, cos I'm puzzled what
>> happened
>>>> here originally  Can you provide more info?
>>>> 
>>>> 
>>>> 
>>>> 2. I have modified the logging.properties but the console ouput is 
>>>> still
>>>>> the same.
>>>> I forgot to say explicitly... there are actually two 
>>>> logging.properties files.  There's the one in WEB-INF (as used by 
>>>> the app), and there's the one in the root directory of the integtest 
>>>> module.
>>>> 
>>>> Did you change both?
>>>> 
>>>> Dan
>>>> 
>>>> 
>>>> 
>>>>> Thanks
>>>>> Dharmesh
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Dan Haywood [mailto:[email protected]]
>>>>> Sent: Monday, March 03, 2014 11:17 AM
>>>>> To: users
>>>>> Subject: Re: Integration testing
>>>>> 
>>>>>> On 3 March 2014 10:49, Chohan, Dharmesh 
>>>>>> <[email protected]>
>>>>> wrote:
>>>>> 
>>>>>> Hi
>>>>>> 
>>>>>> I am running some integration test and I have noticed some 
>>>>>> behaviour that I do not understand.
>>>>>> 
>>>>>> 1.      The following is the output from running the "mvn clean
>>>> install"
>>>>>> command.  The test seems to pass but then I am getting the 
>>>>>> following
>>>>> error.
>>>>>> This is the method called from the test,
>>>>>> 
>>>>>>  public final List<Card> listAll() {
>>>>>>          return allInstances(Card.class);
>>>>>>      }
>>>>>> 
>>>>>>  8 Scenarios (8 passed)
>>>>>>  24 Steps (24 passed)
>>>>>>  0m5.731s
>>>>>> 
>>>>>>  Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>>>>>> 10.852 sec
>>>>>>  Running integration.tests.smoke.EnterTopUpDetailsTest
>>>>>>  Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
>>>>>> 0.14 sec <<< FAILURE!
>>>>>> 
>>>>>>  Results :
>>>>>> 
>>>>>>  Tests in error:
>>>>>>    listAll(integration.tests.smoke.EnterTopUpDetailsTest): Method 
>>>>>> 'allInstances' being invoked does not correspond to any of the 
>>>>>> object's fields or actions.
>>>>> Hmm, I can explain that message, but I'm not exactly sure how it 
>>>>> came to be called.
>>>>> 
>>>>> The message is thrown by the wrapped object, so I'm guessing that 
>>>>> the repository being called is wrapped.  The "listAll" method is 
>>>>> called on the wrapping proxy object that then delegates down to 
>>>>> the underlying wrapped domain object.
>>>>> 
>>>>> What then seems to be happening is that the domain object is 
>>>>> somehow (and I can't quite see how) calling allInstances() back on 
>>>>> the wrapping
>>>> proxy.
>>>>> 
>>>>> Now allInstances is a protected method inherited from 
>>>>> AbstractContainedObject, and protected methods are not recognized 
>>>>> as actions (they must be public).  The proxy is therefore 
>>>>> complaining that it can't find this action.
>>>>> 
>>>>> The workaround would be to override allInstances in your 
>>>>> repository and make it public, or - as you do below - to delegate to the 
>>>>> DOC.
>>>>> But - as I say - I can't quite see how the wrapped domain object 
>>>>> ends up calling back on the wrapping proxy.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> In the same class file I am injecting the DomainObjectContainer 
>>>>>> object with name container.  If I modify the return statement to 
>>>>>> the following, then I get a different error.
>>>>>> 
>>>>>> public final List<Card> listAll() {
>>>>>>       return container.allInstances(Card.class);
>>>>>>   }
>>>>>> 
>>>>>> 8 Scenarios (1 failed, 7 passed)
>>>>>> 24 Steps (1 failed, 2 skipped, 21 passed) 0m5.221s
>>>>>> 
>>>>>> java.lang.NullPointerException
>>>>>>       at
>>>>> net.atos.tfgm.services.CardService.listAll(CardService.java:88)
>>>>>>       at
>>>>> integration.glue.simple.EnterTopUpDetailsGlue$1.<init>(EnterTopUpD
>>>>> etai
>>>>> lsGlue.java:74)
>>>>>>       at
>>>>> integration.glue.simple.EnterTopUpDetailsGlue.There_are_initially_
>>>>> Smar
>>>>> tis_cards(EnterTopUpDetailsGlue.java:72)
>>>>>>       at ?.Given There are initially 3 Smartis 
>>>>>> cards(integration/specs/simple/EnterTopUpDetailsSpec_listAllAndCreate.
>>>>>> feature:28)
>>>>> This looks to me that the container field isn't injected, so its a 
>>>>> simple NPE.  Since you are inheriting from 
>>>>> AbstractContainedObject, use
>>>>> getContainer() instead.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> 2.      The second issue I have seen in the console output is that the
>>>>>> fixtures are getting called 3 times for everything, i.e. create 
>>>>>> table, inserts and selects.  I am not sure if there is something 
>>>>>> in configuration file that needs changing?
>>>>>> 
>>>>>>  10:40:59,946  [Native               main       DEBUG]  INSERT INTO
>>>>>> "Card"
>>>>>> ("expiryDate","cardId","category","type","cardNumber","status","v
>>>>>> ers
>>>>>> io
>>>>>> n")
>>>>>> VALUES
>>>> (<2014-03-03>,<633597111>,<'ITSO'>,<null>,<'123456789111'>,<'Live'>
>>>> ,<1>)
>>>>>>  10:40:59,946  [Native               main       DEBUG]  INSERT INTO
>>>>>> "Card"
>>>>>> ("expiryDate","cardId","category","type","cardNumber","status","v
>>>>>> ers
>>>>>> io
>>>>>> n")
>>>>>> VALUES
>>>> (<2014-03-03>,<633597111>,<'ITSO'>,<null>,<'123456789111'>,<'Live'>
>>>> ,<1>)
>>>>>>  10:40:59,946  [Native               main       DEBUG]  INSERT INTO
>>>>>> "Card"
>>>>>> ("expiryDate","cardId","category","type","cardNumber","status","v
>>>>>> ers
>>>>>> io
>>>>>> n")
>>>>>> VALUES
>>>> (<2014-03-03>,<633597111>,<'ITSO'>,<null>,<'123456789111'>,<'Live'>
>>>> ,<1>)
>>>>>>  1
>>>>> It's only called once, it's just that the logging is setup
>>>> incorrectly....
>>>>> the log4j.additivity clause was missing.
>>>>> 
>>>>> Modify your logging.properties for DataNucleus to read:
>>>>> 
>>>>> 
>>>>> # DataNucleus
>>>>> 
>>>>> # these are the two most useful ones # Native shows DML SQL, 
>>>>> Schema shows DDL SQL 
>>>>> log4j.logger.DataNucleus.Datastore.Native=DEBUG, Console 
>>>>> log4j.logger.DataNucleus.Datastore.Schema=DEBUG, Console
>>>>> 
>>>>> # typically leave the remainder as WARN or ERROR.
>>>>> log4j.logger.DataNucleus.Persistence=WARN, Console 
>>>>> log4j.logger.DataNucleus.Transaction=WARN, Console 
>>>>> log4j.logger.DataNucleus.Connection=WARN, Console 
>>>>> log4j.logger.DataNucleus.Query=WARN, Console 
>>>>> log4j.logger.DataNucleus.Cache=WARN, Console 
>>>>> log4j.logger.DataNucleus.MetaData=WARN, Console 
>>>>> log4j.logger.DataNucleus.Datastore=WARN, Console 
>>>>> log4j.logger.DataNucleus.Datastore.Persist=WARN, Console 
>>>>> log4j.logger.DataNucleus.Datastore.Retrieve=WARN, Console 
>>>>> log4j.logger.DataNucleus.General=WARN, Console 
>>>>> log4j.logger.DataNucleus.Lifecycle=WARN, Console 
>>>>> log4j.logger.DataNucleus.ValueGeneration=WARN, Console 
>>>>> log4j.logger.DataNucleus.Enhancer=WARN, Console 
>>>>> log4j.logger.DataNucleus.SchemaTool=ERROR, Console 
>>>>> log4j.logger.DataNucleus.JDO=WARN, Console 
>>>>> log4j.logger.DataNucleus.JPA=ERROR, Console 
>>>>> log4j.logger.DataNucleus.JCA=WARN, Console 
>>>>> log4j.logger.DataNucleus.IDE=ERROR, Console
>>>>> 
>>>>> log4j.additivity.DataNucleus.Datastore.Native=false
>>>>> log4j.additivity.DataNucleus.Datastore.Schema=false
>>>>> log4j.additivity.DataNucleus.Datastore.Persistence=false
>>>>> log4j.additivity.DataNucleus.Datastore.Transaction=false
>>>>> log4j.additivity.DataNucleus.Datastore.Connection=false
>>>>> log4j.additivity.DataNucleus.Datastore.Query=false
>>>>> log4j.additivity.DataNucleus.Datastore.Cache=false
>>>>> log4j.additivity.DataNucleus.Datastore.MetaData=false
>>>>> log4j.additivity.DataNucleus.Datastore.Datastore=false
>>>>> log4j.additivity.DataNucleus.Datastore.Datastore.Persist=false
>>>>> log4j.additivity.DataNucleus.Datastore.Datastore.Retrieve=false
>>>>> log4j.additivity.DataNucleus.Datastore.General=false
>>>>> log4j.additivity.DataNucleus.Datastore.Lifecycle=false
>>>>> log4j.additivity.DataNucleus.Datastore.ValueGeneration=false
>>>>> log4j.additivity.DataNucleus.Datastore.Enhancer=false
>>>>> log4j.additivity.DataNucleus.Datastore.SchemaTool=false
>>>>> log4j.additivity.DataNucleus.Datastore.JDO=false
>>>>> log4j.additivity.DataNucleus.Datastore.JPA=false
>>>>> log4j.additivity.DataNucleus.Datastore.JCA=false
>>>>> log4j.additivity.DataNucleus.Datastore.IDE=false
>>>>> 
>>>>> 
>>>>> 
>>>>> and see if that fixes the issue.  Hopefully it will, this is the 
>>>>> fix going forward in 1.4.0-snapshot and will be in the next 
>>>>> archetype we release
>>>>> 
>>>>> HTH
>>>>> Dan
>>>>> 
>>>>> 
>>>>> 
>>>>>> Thanks
>>>>>> Dharmesh
>> 

Reply via email to