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 <[email protected]>
escribió:
> On 13 May 2013 14:01, GESCONSULTOR - Óscar Bou <[email protected]>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
>>
>>
