Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

JUnit Tests - Naming Conventions

I am using Interfaces in my persistence layer, as well as for my Business Delegates. These interfaces are named things like UserDAO and UserManager. Their implementations are UserDAOHibernate and UserManagerImpl. First off, I don't know that I need interfaces for my business delegates, but they're already in place, so I'm going with it.

What I'm wonder is if my JUnit TestCases should reflect the Interface name, or the implementation name? UserDAOTest.java or UserDAOHibernateTest.java. I like the first one better, but I tend to hard-code information in it so I can call UserDAOHibernate.java - like the daoType to use. I started out using UserDAOTest because I thought it made more sense - and then it could be used to test all implementations.

Lately, I've been using JUnitDoclet to generate my TestCase skeletons, and it only generates TestCases for concrete classes, not interfaces. Therefore, I've changed to using UserDAOHibernateTest, which can be a helluva lot to type (and remember) when running TestCases! Here's the Ant command I use to run this test:

ant test-ejb -Dtestcase=UserDAOHibernateTest

And User is a short word! Can you imagine what these suckers will look like when I have an object such as ChangeRequest. Ughh. What do you gents think - I'm all ears.

Posted in Java at Jan 03 2003, 04:02:14 PM MST 3 Comments
Comments:

If you have the ${testcase} in your build file being used as **/*${testcase}* then you won't be required to type the whole class name - just an FYI.... but it'll of course run every test that matches, which is not likely to be many if more than one.

Posted by Erik Hatcher on January 03, 2003 at 10:31 PM MST #

So you're saying I could type: <code>-Dtestcase=UserDAO</code> and it would call <code>UserDAOHibernateTest</code>? If so, that's fricken sweeet and just another reason why I like your build.xml so much - even if it was a headache to try and convince my new co-workers to use it. My only defense for 3 different trees (common, ejb, web) was for Unit Testing and packaging, which I think is a great reason.

Posted by Matt Raible on January 03, 2003 at 10:52 PM MST #

In my application, I have a etm.farrago.model which contains the persistence layer in POJOs. Almost no niterfaces. The POJOs get passed over RMI to a PersistenceService (session bean) which uses Hibernate (or whatever) to persist the objects. I wrote a PersistenceServiceUnitTest that creates my entire model, and submits it to the PersistenceService. It then retrieves it and does a deep compare. What about that?

Posted by Mathias Bogaert on January 04, 2003 at 04:04 AM MST #

Post a Comment:
  • HTML Syntax: Allowed