...
- A mock of BrowseCreateDAOOracle has been done due to an incompatibility between H2 and the "upper" function call. This will affect tests related to case sensitivity in indexes.
- Many objects (like SupervisedItem) lack a proper definition of the "equals" method, which makes comparison between objects and unit testing harder
- Update method of many objects doesn't provide any feedback, we can only test if it raises an exception or not, but we can't be 100% sure if it worked
- Many objects have methods to change the policies related to the object or children objects (like Item), it would be good to have some methods to retrieve these policies also in the same object (code coherence)
- There are some inconsistencies in the calls to certain methods. For example getName returns an empty String in a Collection where the name is not set, but a null in an Item without name
- DCDate: the tests raise many errors. I can't be sure if it's due to misunderstanding of the purpose of the methods or due to faulty implementation (probably the previous). In some cases extra encapsulation of the internals of the class would be advisable, to hide the complexities of the Calendars (months starting by 0, etc)
- The Authorization system gets a bit confusing. We have AuthorizationManager, AuthorizationUtils, methods that raise exceptions and methods that return booleans. Given the number of checks we have to do for permissions, and that some classes call methods that require extra permissions not declared or visible at first, this makes creation of tests (and usage of the API) a bit complex. I know we can ignore all permissions via context (turning on and off authorizations) but usually we don't want that
- Bitstream: there are no checks to ensure a bitstream has been deleted. The removal is logical (flag in database) so a method to verify that would be advisable (at least for the purpose of testing)
- Community: set logo checks for authorization, but set metadata doesn't. It's in purpose?Community: when you create a subcommunity, it is not added as a child straight away
- Collection: methods create and delete don't check for authorization
- FormatIdentifier: there is an error when checking if the filename is null, as the method lowerCase is called before the check, raising NPE is the entry is null.
- Item: there is no authorization check for changing policies, no need to be an administrator
- ItemIterator: it uses ArrayLists in the methods instead of List
- ItemIterator: we can't verify if the Iterator has been closed
- LicenseUtils: the template systems seems faulty. When using the parameters, %0 and %1 return the same value
- of List
- ItemIterator: we can't verify if the Iterator has been closedSite: this class has some empty methods, like delete or update
- Site: this class extends DSpaceObject. With it being a Singleton, it creates potential problems, for example when we use DSpaceObject methods to store details in the object. It's this relation necessary?SupervisedItem: seems to have some issue when finding items by EPerson
Proposals:
To solve the previous issues, some proposals are done:
...
| Code Block |
|---|
mvn package -Dmaven.test.skip=truefalse or with mvn package -P!skiptests |
or by changing the property "activeByDefault" at the corresponding profile (skiptests) in the main pom.xml file, at the root of the project.
...