Databases
StackOverflow2013
Postsdbo
POWhat can go wrong in hibernate domain classes – so that we need to (unit) test them?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POWhat can go wrong in hibernate domain classes – so that we need to (unit) test them?
    primarykey
    data
    text
    <p><strong>What can go wrong?</strong></p> <p>I have started writing hibernate domain classes for my new J2EE project and during my initial analysis I felt that the following things can go wrong in domain classes that warrants me to have automated tests written for them to capture them in advance:</p> <ol> <li>Attribute/column mappings – I might by mistake configure a wrong column to a given attribute in the domain class</li> <li>I might change the database column name(s) and forget to change the corresponding mapping(s) in the domain class file</li> <li>I might forget to set the object attribute in the constructor. This can happen during the class creation time or while testing something by commenting out some attributes but forgetting to un-comment them back. (I have done this mistake in real life).</li> <li>I have NOT defined the attributes with the correct data types for the corresponding database column types.</li> <li>Boundary conditions testing to ensure that we have the right sized data types defined for the attributes. This will also capture any inadvertent changes to the data types in the future, say from long to int.</li> </ol> <p>Whether testing a domain class against these changes is called unit testing or not, I am not really sure as it involved database while testing. What I need is a way to test my domain classes to ensure that they are NOT broken due to any such above mentioned changes, inadvertently, of-course.</p> <p>Important Assumption: The database entities (tables, constraints, indexes) have been created accurately and there are no errors in them, as in, the data types, size etc. have been defined accurately. In other words, as part of the ‘(unit) testing of the domain classes’, we won’t be testing the schema for potential errors. Examples below: * Data types and their sizes are correct * If required constraints (PK, FK, UK, indexes etc.) are present and they are correct</p> <p><strong>Automated testing of the domain classes</strong></p> <p>For issues 1, 2, 4 - Use: validate in hibernate configuration file. A simple test to save a record (just mandatory fields is enough) into the table(s) concerned will ensure that these issues are not present in the mappings. Assertion: There should not be any exception thrown.</p> <p>For issue 3 – A simple test to save a record with all the fields will capture if there is any field left out. Assertion: There should not be any exception thrown.</p> <p>For issue 5 – Test case is needed that will insert a record with all the fields with max boundary conditions. Assertion: There should not be any exception thrown.</p> <p>Summary: A test case to save a record with all the fields populated with max boundary values will be good enough to test the hibernate domain classes. Assertion: There should not be any exception thrown.</p> <p><strong>Questions</strong></p> <ol> <li>Does the above argument make sense? If not, why?</li> <li>If it makes sense, what is the right technology for the actual implementation? Would that be JUnit or TestNG, etc.?</li> </ol> <p>Thanks in advance for your inputs.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USPhantomReference
    plurals
    1. This table or related slice is empty.
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POWhat can go wrong in hibernate domain classes – so that we need to (unit) test them?
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload