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.

RECENT ENTRIES


Tag Cloud


abbie appfuse birthday denver family grails gwt jack java javascript jsf linkedin maven montana roller skiing softwaresummit spring springmvc struts2 travel trish vacation webframeworks wicket
« Tapestry vs. Struts | Main | What's new in Tomcat... »
Wednesday January 28, 2004

RE: Mock Shmocks!

After I finished reading Open Source Programming and all the of the feedback from my Mock Shmocks post, I've realized that I need to learn more about Mocks. I need to learn how to streamline my TDD process. It's just taking too long right now. So where do I go from here? AppFuse currently contains, from what I can tell, only integration tests. All the tests depend on the database or the container to run. It works great, and all of AppFuse's tests complete under 3 minutes, but obviously this time increases as the project grows. So should I remove some integration tests and replace them with unit (mock) tests? If so, which ones? Should UserDAOTest talk to the database, but LookupDAOTest only use a Mock? How do you decide which tests should be real (integration) and which tests don't need to be (mocks)?

If the answer is "create a unit tests to sit next to each one of your integration tests" - then that seems like a waste of time. Am I supposed to have 2 *Test.java classes for each real class? I need a book that'll explain all of this and make me the TDD guru I long to be.

Even if I figured out all the answers to the above questions - which package should I use? There's a whole slew of them: Mockrunner, MockObjects, EasyMock and jMock. How do you decide? It's easy when testing Java classes - you use JUnit. When you want to test servlets, you use Cactus. Why all the choices for Mock testing?

Posted in Java at Jan 28 2004, 10:18:17 PM MST 6 Comments
Comments:

IMO you need two things, one to use DbUnit tests to test your database stuff, two use Mocks in your layer relation tests. I've used MockObjects for most of this. Their API seems to be the most robust, but their API docs are somewhat lacking. I haven't tried the other mock technologies, so maybe they're better than MockObjects. The other thing I've found really useful for mock-ing is AOP mocks. That way you don't have to make everything an interface. You can actually stub out behavior at test time w/o changing a boatload of code. It's very handy if you're using third party libraries.

Posted by Keith Sader on January 29, 2004 at 10:07 AM MST #

BTW, hope you're feeling better.

Posted by Keith Sader on January 29, 2004 at 10:08 AM MST #

This is my rule: So you're writing TestX for class X. X uses Y and Z too (dependencies). Considering that you're following the Dependency Injection pattern, you must create an instance of Y and Z and set them on the X instance that you're going to test. I would say just setY((Y)mockY.proxy()); but if Y is easily instansiated and is fastly instansiated then just setY(new Y()); :-) With TDD I beleive this mock apparoach works best, because you start from the test and you should set an instance of Y and Y and a concrete DefaultY class is not implemeneted at all. So by using mocks you can handle it more easily, you can shape the contract of Y interface more easily without worrying about Y's implementation, and remember you're testing X not Y so mocking Y is ok for now.

Ara.

Posted by Ara on January 29, 2004 at 11:35 AM MST #

I can understand your reasons to look at mocks and I totally agree that they are useful for removing dependencies with infrastructure components such as web servers. However, I must stress that mock objects have *nothing* to do with TDD! If AppFuse contains only integration tests then you aren't doing test driven development. Hmmm ... I feel a blog entry coming on... ;-)

Posted by Simon Brown on January 29, 2004 at 05:25 PM MST #

Write a test before writing a class - isn't that TDD at a minimum? The fact that I wrote my tests before I wrote my classes makes me <em>think</em> I'm doing TDD. If I'm wrong - <em>please</em> enlighten me!

Posted by Matt Raible on January 29, 2004 at 05:44 PM MST #

OK, I did some googling and found this definition of Test Driven Development. Sure it's really about "designing" your application in your tests - but in reality - you still have to write the damn tests to be doing TDD! ;-)

Posted by Matt Raible on January 29, 2004 at 05:50 PM MST #

Post a Comment:
  • HTML Syntax: Allowed