Win a copy of Java Challengers this week in the Java in General forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • paul wheaton
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Liutauras Vilda
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Piet Souris
Bartenders:
  • salvin francis
  • Mikalai Zaikin
  • Himai Minh

Head First Java - Unit Testing Guidelines?

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

I am going through Head First Java.
There is a Battle Ship game project that evolves from a simple to a more advanced version.
When they cover the simple one, they show an example on how to write a class for testing the app with just plain java. Later on, when moving on to the advanced version, they basically say "we don't show you more testing code, go figure it out".
That would not be a problem if at least I could get some guidelines or resources.

Should I follow the book's example of writing pure java to test? Should I look into jUnit? groovy?
What is a proper way to test that fits today's expected quality standards?

According to the book I am supposed to write tests before each app, but without any guidance I will end up writing a bunch of none sense that wont help me get hired anywhere.

TY
 
Rancher
Posts: 961
23
Netbeans IDE Oracle MySQL Database Tomcat Server C++ Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I go with this general rule of thumb: What does your employer want you to do?  Do that.


In your case, learn how to do both.
 
Saloon Keeper
Posts: 12893
280
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Les Morgan wrote:I go with this general rule of thumb: What does your employer want you to do?  Do that.


I think you mean the project's technical lead. And even then, I think it's a good idea for team members to educate themselves and to experiment. If it's wrong, it should come up in code review.

Anyway, you start a unit test by deciding what you want to test. Pick a specific set of circumstances, and make a specific assertion about that set of circumstances. Then perform the following steps in your unit test:

1. Mock dependencies.
2. Configure test object.
3. Configure expected exceptions.
4. Call test object.
5. Make an assertion about the return value or application state.
6. Verify calls on mocked dependencies.

Here is an example:
 
Sheriff
Posts: 16146
269
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Kenneth Pino wrote:Should I follow the book's example of writing pure java to test?


What kind of pure? If you're talking about just plain old hand-written Java code that you wrote, then definitely not. In the real-world, you need to use something more robust.

Should I look into jUnit? groovy?


Definitely yes for JUnit. That's the de facto standard for testing frameworks in Java. I'd encourage you to look at Groovy and Spock in particular. Spock allows you to write really beautiful tests and since it runs on the JVM, you can add it to any Java project.

What is a proper way to test that fits today's expected quality standards?


What kind of proper is your proper? That is, what do you define as "proper?"

To me "proper" can mean a few different things:

1. Proper testing should be primarily automated. It should be fast and incorporated in your development process (you do it constantly as you write code and work through your design). Manual testing should be reserved for exploratory testing.

2. It should be mostly unit tests, followed by integration tests, and then the least would be UI-based. These are proportions based on the idea of the testing pyramid. Many teams test with an "ice cream cone" model, with most testing being UI-based and little to none is automated unit testing. Pyramid good, Ice Cream Cone bad.

3. It should be collaborative. Tests should be understood by all involved, including the business people. When automating, test-focused people (testers) and developers should collaborate to define the test plan and make sure there's no duplication of effort.

4. Tests drive your design process. I prefer the Test-Driven Development (TDD) and Behavior-Driven Development (BDD) approaches. These approaches are focused on design being an integral and continuous part of the development process. With TDD and BDD, tests become executable design specifications.

There are more ways you can see "proper" testing but I'll stop here and see how all that lands with you.
 
Junilu Lacar
Sheriff
Posts: 16146
269
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I cringe a little when thinking about mocking dependencies but it's a necessary thing to consider when talking about unit testing. Most classes do not exist in a vacuum and will require collaborators to do a job. This is where testing with test doubles and mocks comes in.

That said, try to keep your designs simple so you don't have to mock too many things or you can use simpler fakes and stubs for most of your dependencies. If you find yourself writing test code that is mostly about setting up complicated mock objects and their behaviors as dependencies to the class under test, you should consider that as a "code smell" and try to see if you can refactor your design to reduce the number of dependencies your class under test has and/or to make its interaction with those dependencies simpler.
 
Junilu Lacar
Sheriff
Posts: 16146
269
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are many things of note in Stephan's example. Study it carefully because it exhibits many attributes of what most consider to be the "proper" way to write unit tests.

The first thing I'd point out is the test method name. It expresses the test's intent very well. Most people don't spend enough time on the test name, or any name they choose in their programs for that matter. The names you choose in your program play a crucial role in the quality of your code. A well-chosen name will save you and others time and effort by making it easier to understand the context of what's going on in the code. This is true for any kind of code, including test code.

Think of a test method name as a summary of the story that the test is trying to tell. If you're browsing though a list of movies trying to decide which one you want to watch, you're more likely to choose one that has a well-written summary. Same idea for a test name. If you're browsing though a bunch of tests to see which ones exercise some behavior you're interested in exploring, good test names will help you figure that out with the least amount of effort possible.

Stephan's list of things you should do when writing a test is pretty comprehensive but you should note that you won't necessarily do all those things every time you write a test. It does follow the more general pattern of AAA - Arrange, Act, Assert which should apply to all tests you write. That's basically the general outline for any test.
 
Kenneth Pino
Greenhorn
Posts: 4
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you all so much for all the replies.
I got exactly the information I was looking for.

And TY for that example
 
reply
    Bookmark Topic Watch Topic
  • New Topic