Pragmatic Unit Testing in Java 8 with JUnit: Java 8-specific strategies?

[Junilu Lacar]

I've been slowly going through the book and so far so good. It's a great refresher course and I've even learned a few more things along the way. I've seen quite a number of unit test examples that use lambda expressions, method references, and streams and that's great too. I honestly haven't had the opportunity to use Java 8 at work yet so I haven't had to deal with issues related to testing code that uses the new language features. However, just thinking about, it seems there could be some challenges in testing code that uses lambdas, method references, and the stream API. I try to keep my code and designs as simple as possible to make it easier to test but I can't really say the same for other developers whose code I have to deal with, too.

Skimming ahead, I see that Chapter 13, "Testing Some Tough Stuff," looks promising -- I'll have to read that more thoroughly later. Would you like to give the folks here a summary of the things you touch on in that chapter and perhaps other situations/examples you can think of that might not make it into the book when it goes to final print?

Aside: What's the story behind the name "iloveyouboss"? I'm really itching to know.

[Jeff Langr]

Hi Junilu,

Thanks for the comments on the book!

The "tough stuff" chapter covers an example of testing databases and an example of testing threads--usually two things that folks scratch their head about when doing unit testing.

I view lambdas as implementation details--you're going to test methods that use them in the same way as before. It's still inputs, outputs, and side effects (and with lambdas, you shouldn't generally be having any of those).

The idea for the core example in the book is a match-making system that helps put together employers and prospective employees--much like eHarmony, the idea would be to make sure that each is compatible with the other by comparing answers for a series of questions. I needed a pithy, simple unforgettable name, and "iloveyouboss" just popped into my head. I still think it's funny.

Jeff

[atul khot]

Hi Jeff,
Testing multi-threaded code is really intriguing one ;-)
- I used to wonder a lot at this - and then kind of stumbled upon the wonderful concept of "Active Objects"
(https://pragprog.com/magazines/2013-05/java-active-objects)...
So do we really have to worry about testing multi-threaded code?

--- regards atul

[Jeff Langr]

Hi Atul,

Even painstakingly careful analysis of multi-threaded code can fail to reveal insidious concurrency defects that often don't surface well into production use.

The best approach is to use well-tested libraries (e.g. Lea's Java 5 concurrency library) and minimize the amount of code that requires concurrent execution. Think "separation of concerns" between threading needs and business (application) logic.

There's a small threading example in the book that covers how to factor your code to this end. Also, if you take a look at Modern C++ Programming with Test-Driven Development, I demonstrate how you might test-drive threading needs.

http://blog.narmnevis.com/2011/03/implementing-active-object-pattern-with-concurrent-java-1/ -- one demonstration of using the Java concurrency API to implement active object.

Regards,
Jeff