Instructor Feedback - Week 5

[pawaitemadisoncollege]

Nice job working in that one-to-many in your project along with that generic dao! I also think you'll find Jeanne's presentation this coming Monday really interesting - she'll be sharing how to implement Lombok which will significantly reduce your lines of code in the entities!

• [x] To ease maintenance, it makes sense to create a separate DaoTest for each entity, so these methods should really be in a LocationDao unit test as they are testing the Location more than they are testing the user. https://github.com/kkelm/adhound/blob/7c18b884e328c2be057e6ac7f52c365a5e7bf456/src/test/java/com/adhound/persistence/UserDataTest.java#L115-L190
• [x] Is this line necessary? https://github.com/kkelm/adhound/blob/7c18b884e328c2be057e6ac7f52c365a5e7bf456/src/test/java/com/adhound/persistence/UserDataTest.java#L180
• [ ] What should be asserted here to make sure the test worked?
• [ ] To thoroughly test the relationship, if a location is deleted, is the user also deleted? Add a test to make sure what is supposed to happen, happens.
• [ ] In a similar way, if a user is deleted, should the location be deleted? What actually happens? Write a test to prove it and also make sure that functionality remains in tact through future development.
• [ ] Also a reminder to improve the thoroughness of assertions by implementing and using an equals() method to compare entire entities.

[kkelm]

• I worked on the first bullet point today. Yeah, I thought the tests should be separated, so I worked on the Location tests today.
• I was wondering if userLocations.remove was really necessary because I played around with it, and my Location crud.deleteRecord seemed to take care of it. Initially in my mind I had the location in 2 places the User object and the Location object, so it needed to be removed in both locations. But after some playing around today I see I can just get rid of the the userLocations.remove.
• If I'm answering this question correctly. When it comes to what should be asserted boils down to what has changed... Did something get added? Then what? Did something get removed? What? Did something get changed? Specifically what changed? All of those could be check with either an equals, true/false, or null assertion.
• Bullet points 4 and 5. On the foreign key that links the user to a location in the locations table, I have a CASCADE ON DELETE, so when a user is deleted the user's locations get deleted too. I plan to use this method all the way down the hierarchy from the user to the panel at a location.
• I think to efficiently and more thoroughly test things is going to be comparing an entire object.
• I got ahead of myself when I submitted this for review, because I just watched the video on .equals.