You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> on 2013/05/10 20:43:22 UTC

wrapped objects are told to not being persisted. Is it correct?

I'm not sure if this is the expected behaviour while testing Domain Objects through the JUnit viewer.

While doing tests over factory actions, one assert would be to verify the object has been persisted through the DomainObjectContainer.isPersistent(domainObject) method. 

If the evaluation is done over a wrapped object, it returns false.

If it's done over the original object, it returns true.

As an example:

		// Test if the Domain Object has been persisted.
		assertTrue(domainObjectContainer
				.isPersistent(communicationPathAssociatedWithNode));

		// Node must be wrapped for the Apache Isis validators to be executed.
		communicationPathAssociatedWithNode = wrapped(communicationPathAssociatedWithNode);

		assertTrue(domainObjectContainer
				.isPersistent(communicationPathAssociatedWithNode));


The last assertion fails. The only difference I expected was the validation of the programming model. Is it correct? I'm sure there's anything I'm missing.

Thanks in advance!


Re: wrapped objects are told to not being persisted. Is it correct?

Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
We didn't thought about implementing DomainObjectContainer. We will explore that. Thanks for pointing that out.

We were experimenting now about implementing "common work" on abstract repositories (for all Domain Objects, for Multi-Tenant Entities, etc.) that are inherited for each .

This method was called only on tests for factory methods on those repositories, in order to avoid forgotten "persist()", initialization without all mandatory fields as defined by the Isis programming model, and other future validations.







El 14/05/2013, a las 12:47, Dan Haywood <da...@haywood-associates.co.uk> escribió:

> On 14 May 2013 11:33, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
> 
>> 
>> Your experiment is working nicely! :-))
>> 
>> We have defined an abstract base test class with the following validation
>> method, that it's called for testing any DomainObject creation. Is there
>> anything redundant? Any other generic validations we could perform specific
>> for Apache Isis? Any comment that it's not correct?
>> 
> 
> 
> the last line in the method...
> 
> domainObject = wrapped(domainObject);
> 
> isn't going to do anything; Java is pass-by-value, not pass-by-reference.
> 
> The rest looks ok, though I wonder whether you should require all your
> tests to make these assertions; you could probably test more generally
> elsewhere.
> 
> For example, you could register your own implementation of
> DomainObjectContainer, and then it could ensure that each domain Object's
> getId() is populated as a post-condition check.  You would therefore just
> need to unit test your DOC implementation in one place only.
> 
> You might also move the call to validate(...) into your DOC impl too.
> 
> Cheers
> Dan
> 
> 
> 
>> 
>> /**
>>         * @param communicationPathAssociatedWithNode
>>         */
>>        public void validateCommonAssertions(DomainObject domainObject) {
>> 
>>                // The Business Id. must be assigned.
>>                assertTrue(!domainObject.getId().isEmpty());
>> 
>>                // Test if the Domain Object has been persisted.
>> 
>> assertTrue(this.getDomainObjectContainer().isPersistent(domainObject));
>> 
>>                // Validation must be invoked over the original Domain
>> Object, not the
>>                // wrapped object (it would fail for setters of Services
>> injected to the
>>                // Domain Object).
>> 
>> assertTrue(this.getDomainObjectContainer().validate(domainObject) == null);
>> 
>>                // Node must be wrapped for the Apache Isis validators to
>> be launched.
>>                domainObject = wrapped(domainObject);
>> 
>>        }
>> 
>> Thanks,
>> 
>> Oscar
>> 
>> 


Re: wrapped objects are told to not being persisted. Is it correct?

Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 14 May 2013 11:33, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:

>
> Your experiment is working nicely! :-))
>
> We have defined an abstract base test class with the following validation
> method, that it's called for testing any DomainObject creation. Is there
> anything redundant? Any other generic validations we could perform specific
> for Apache Isis? Any comment that it's not correct?
>


the last line in the method...

domainObject = wrapped(domainObject);

isn't going to do anything; Java is pass-by-value, not pass-by-reference.

The rest looks ok, though I wonder whether you should require all your
tests to make these assertions; you could probably test more generally
elsewhere.

For example, you could register your own implementation of
DomainObjectContainer, and then it could ensure that each domain Object's
getId() is populated as a post-condition check.  You would therefore just
need to unit test your DOC implementation in one place only.

You might also move the call to validate(...) into your DOC impl too.

Cheers
Dan



>
> /**
>          * @param communicationPathAssociatedWithNode
>          */
>         public void validateCommonAssertions(DomainObject domainObject) {
>
>                 // The Business Id. must be assigned.
>                 assertTrue(!domainObject.getId().isEmpty());
>
>                 // Test if the Domain Object has been persisted.
>
> assertTrue(this.getDomainObjectContainer().isPersistent(domainObject));
>
>                 // Validation must be invoked over the original Domain
> Object, not the
>                 // wrapped object (it would fail for setters of Services
> injected to the
>                 // Domain Object).
>
> assertTrue(this.getDomainObjectContainer().validate(domainObject) == null);
>
>                 // Node must be wrapped for the Apache Isis validators to
> be launched.
>                 domainObject = wrapped(domainObject);
>
>         }
>
> Thanks,
>
> Oscar
>
>

Re: wrapped objects are told to not being persisted. Is it correct?

Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Your experiment is working nicely! :-))

We have defined an abstract base test class with the following validation method, that it's called for testing any DomainObject creation. Is there anything redundant? Any other generic validations we could perform specific for Apache Isis? Any comment that it's not correct?

/**
	 * @param communicationPathAssociatedWithNode
	 */
	public void validateCommonAssertions(DomainObject domainObject) {

		// The Business Id. must be assigned.
		assertTrue(!domainObject.getId().isEmpty());

		// Test if the Domain Object has been persisted.
		assertTrue(this.getDomainObjectContainer().isPersistent(domainObject));

		// Validation must be invoked over the original Domain Object, not the
		// wrapped object (it would fail for setters of Services injected to the
		// Domain Object).
		assertTrue(this.getDomainObjectContainer().validate(domainObject) == null);

		// Node must be wrapped for the Apache Isis validators to be launched.
		domainObject = wrapped(domainObject);

	}

Thanks,

Oscar



El 14/05/2013, a las 08:38, Dan Haywood <da...@haywood-associates.co.uk> escribió:

> On 13 May 2013 14:01, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
> 
>> 
>> Hi, Dan.
>> 
>> Thanks for all the answers.
>> 
>> Regarding the JUnit, my vote would be for releasing it :-)
>> 
>> It's really, really useful with current functionalities, validating all
>> actions, beahviours, etc. from JUnit without effort.
>> 
>> This "functionality" can give quite points to the framework to anyone
>> evaluating it.
>> 
>> 
> That's nice to hear, actually.  I suspect you are the first team using it
> earnest (on Estatio we mostly are just writing integration tests).  So I'm
> glad that - what I wrote as a little experiment a few years back - actually
> does work.
> 
> 
> 
> 
>> This one is the only "bug" found until now. And it couldn't be considered
>> as a bug, but an improvement over current functionality, if "wrapping" an
>> object would mean only to "wrap" the Domain Object properties, and not the
>> framework's related ones (such as if it's persisted).
>> 
>> 
> In which case it's a documentation bug, I suppose.  It ought to be possible
> to fix, though.
> 
> 
> 
> 
>> The problem is that, as it's not released, it's not present on any maven
>> repository, and forces to download and compile the current snapshop, and
>> install the junit viewer jar on the local maven repository.
>> 
>> 
> Perhaps a compromise might be for me to release it out as a snapshot
> release for now?  (but depending only on the other released code so that
> you can keep as "official" as possible,
> 
> 
> 
>> But I understand that you don't want to release it if big changes on its
>> API are planned. But if finally it's released, an option would be to
>> "mothball" it when the new Apache Isis testing framework that integrates
>> JUnit and BDD functionalities will be released.
>> 
>> 
> Yes, that's a possibility.  It's not a very good name, anyway, is it.  I
> shall mull on this.
> 
> 
> Cheers,
>> 
>> Oscar
>> 
>> 


Re: wrapped objects are told to not being persisted. Is it correct?

Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 13 May 2013 14:01, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:

>
> Hi, Dan.
>
> Thanks for all the answers.
>
> Regarding the JUnit, my vote would be for releasing it :-)
>
> It's really, really useful with current functionalities, validating all
> actions, beahviours, etc. from JUnit without effort.
>
> This "functionality" can give quite points to the framework to anyone
> evaluating it.
>
>
That's nice to hear, actually.  I suspect you are the first team using it
earnest (on Estatio we mostly are just writing integration tests).  So I'm
glad that - what I wrote as a little experiment a few years back - actually
does work.




> This one is the only "bug" found until now. And it couldn't be considered
> as a bug, but an improvement over current functionality, if "wrapping" an
> object would mean only to "wrap" the Domain Object properties, and not the
> framework's related ones (such as if it's persisted).
>
>
In which case it's a documentation bug, I suppose.  It ought to be possible
to fix, though.




> The problem is that, as it's not released, it's not present on any maven
> repository, and forces to download and compile the current snapshop, and
> install the junit viewer jar on the local maven repository.
>
>
Perhaps a compromise might be for me to release it out as a snapshot
release for now?  (but depending only on the other released code so that
you can keep as "official" as possible,



> But I understand that you don't want to release it if big changes on its
> API are planned. But if finally it's released, an option would be to
> "mothball" it when the new Apache Isis testing framework that integrates
> JUnit and BDD functionalities will be released.
>
>
Yes, that's a possibility.  It's not a very good name, anyway, is it.  I
shall mull on this.


Cheers,
>
> Oscar
>
>

Re: wrapped objects are told to not being persisted. Is it correct?

Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Hi, Dan.

Thanks for all the answers.

Regarding the JUnit, my vote would be for releasing it :-) 

It's really, really useful with current functionalities, validating all actions, beahviours, etc. from JUnit without effort.

This "functionality" can give quite points to the framework to anyone evaluating it. 

This one is the only "bug" found until now. And it couldn't be considered as a bug, but an improvement over current functionality, if "wrapping" an object would mean only to "wrap" the Domain Object properties, and not the framework's related ones (such as if it's persisted).

The problem is that, as it's not released, it's not present on any maven repository, and forces to download and compile the current snapshop, and install the junit viewer jar on the local maven repository.

But I understand that you don't want to release it if big changes on its API are planned. But if finally it's released, an option would be to "mothball" it when the new Apache Isis testing framework that integrates JUnit and BDD functionalities will be released.

Cheers,

Oscar
 



El 12/05/2013, a las 17:30, Dan Haywood <da...@haywood-associates.co.uk> escribió:

> Oscar,
> This sounds like a bug.  Perhaps raise a ticket for it?
> 
> That said, I'm afraid I don't have the bandwidth at the moment to
> investigate; as I said, my focus at the moment is making sure all the
> formally released code is working well, and is why I'd rather not be
> releasing the JUnit viewer yet.
> 
> But if you are relying heavily on the JUnit viewer (as it looks like you
> are), and you want to help take this forward to a formal release, then I'm
> happy to explain the ideas I have for developing it, so you can take it
> forward as a contribution back to Isis if you wish.
> 
> Cheers
> Dan
> 
> 
> 
> 
> On 10 May 2013 19:43, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
> 
>> 
>> I'm not sure if this is the expected behaviour while testing Domain
>> Objects through the JUnit viewer.
>> 
>> While doing tests over factory actions, one assert would be to verify the
>> object has been persisted through the
>> DomainObjectContainer.isPersistent(domainObject) method.
>> 
>> If the evaluation is done over a wrapped object, it returns false.
>> 
>> If it's done over the original object, it returns true.
>> 
>> As an example:
>> 
>>                // Test if the Domain Object has been persisted.
>>                assertTrue(domainObjectContainer
>> 
>> .isPersistent(communicationPathAssociatedWithNode));
>> 
>>                // Node must be wrapped for the Apache Isis validators to
>> be executed.
>>                communicationPathAssociatedWithNode =
>> wrapped(communicationPathAssociatedWithNode);
>> 
>>                assertTrue(domainObjectContainer
>> 
>> .isPersistent(communicationPathAssociatedWithNode));
>> 
>> 
>> The last assertion fails. The only difference I expected was the
>> validation of the programming model. Is it correct? I'm sure there's
>> anything I'm missing.
>> 
>> Thanks in advance!
>> 
>> 


Re: wrapped objects are told to not being persisted. Is it correct?

Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Oscar,
This sounds like a bug.  Perhaps raise a ticket for it?

That said, I'm afraid I don't have the bandwidth at the moment to
investigate; as I said, my focus at the moment is making sure all the
formally released code is working well, and is why I'd rather not be
releasing the JUnit viewer yet.

But if you are relying heavily on the JUnit viewer (as it looks like you
are), and you want to help take this forward to a formal release, then I'm
happy to explain the ideas I have for developing it, so you can take it
forward as a contribution back to Isis if you wish.

Cheers
Dan




On 10 May 2013 19:43, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:

>
> I'm not sure if this is the expected behaviour while testing Domain
> Objects through the JUnit viewer.
>
> While doing tests over factory actions, one assert would be to verify the
> object has been persisted through the
> DomainObjectContainer.isPersistent(domainObject) method.
>
> If the evaluation is done over a wrapped object, it returns false.
>
> If it's done over the original object, it returns true.
>
> As an example:
>
>                 // Test if the Domain Object has been persisted.
>                 assertTrue(domainObjectContainer
>
> .isPersistent(communicationPathAssociatedWithNode));
>
>                 // Node must be wrapped for the Apache Isis validators to
> be executed.
>                 communicationPathAssociatedWithNode =
> wrapped(communicationPathAssociatedWithNode);
>
>                 assertTrue(domainObjectContainer
>
> .isPersistent(communicationPathAssociatedWithNode));
>
>
> The last assertion fails. The only difference I expected was the
> validation of the programming model. Is it correct? I'm sure there's
> anything I'm missing.
>
> Thanks in advance!
>
>