[latch]

This is the first controller I opened from their samples[1] :

  public class Forums extends Application {
    public static void index() {
      List forums = Forum.findAll();
      long topicsCount = Topic.count();
      long postsCount = Post.count();
      render(forums, topicsCount, postsCount);
    }
  ...
  }

You can't mock out Forum, Topic or Post. You can't inject some type of "FormRepository" or whatever pattern you want to gain some type of control. In Ruby, or most dynamic languages, this wouldn't be a problem, since a class method can (and should) be mocked. Even if a static language allows for that sort of trickery (for example, there are a couple ways to test the above in C#), it's the wrong approach. Dependencies should be injected and thus controlled. I guess you could inject using static setters, but that's just a bad workaround to what, in my opinion, is a fundamental misunderstanding of how to write testable code.

[1] https://github.com/playframework/play/blob/master/samples-an...

[elshimone]

If you wanted to unit test this I'm confident you could do it using JMockit [1] without changing the code. JMockit allows you to mock just about anything (static methods, final methods, constructor invocations). The unit test might look something like:

  @Test
  public void checkIndexRenders()
  {
    final List expectedforums= new ArrayList(asList(TEST_FORUM)); 
    new NonStrictExpections()
    {
      @Mocked Forum forum;
      @Mocked Topic topic;
      @Mocked Post post;
      {
        Forum.findAll(); result = expectedforums;
        Topic.count(); result = 5;
        Post.count(); result = 10;
      }
    };

    Forums.index()
    // your assertions ...
  }

I come from a DI background, but the JMockit framework has changed my view of what untestable code is.

[1] http://code.google.com/p/jmockit/

[draebek]

Apologies for the tangent, but is this considered idiomatic Java these days? As a person who knows/knew Java pretty well but has been out of the game for a few years, this code seems highly surprising. Instantiating an anonymous subclass with a static initializer to... I suppose be able to use those @Mocked annotations. Then assigning result in that anonymous initializer block, which I must assume works through black magic.

No criticism of your code example. I think figuring out how to make Java do this is very impressive. I just wonder if it's considered wise to do this sort of thing in production code?

(Edited to correct that I don't think that's a static initializer block.)

[ZitchDog]

Generally this would not be done in production code. jMockit is pretty out there, syntax - wise, and the anonymous inner classes are generally discouraged in production code. In tests are generally fine though. which is why jMockit can get away with it.

[TylerE]

What, exactly, is the POINT of unit-testing that function, other than patting yourself on the back? You might as well unit test that 1+1 = 2.

[latch]

Unit testing isn't really about ensuring correctness.

First and foremost, it's a design tool. Code that can't easily be unit tested is often poorly designed. The most common example in the MVC-world is a fat controller. It's hard to test any method that does too much because of all the setup that you'll have to do. If an action is doing too much, dependent on too many parts, and not very cohesive, you'll feel the pain when you try to test it.

Of course, it's just an indicator...a warning symbol. Some times method need to do a lot...sometimes they do a lot while being cohesive and not having a lot of dependencies. Ultimately, your brain is the judge, a unit test is just a tool to help measure a method's entropy.

Secondly, it's a refactoring tool. Or, put differently, it's about future correctness. Broadly speaking, in this sense, it's also documentation. At a unit test level, this is tricky...and I've struggled with it quite a bit...if you overly concern yourself with internals (using a strict mock), you'll have a brittle test which is largely focused on the current correctness. However, using loose stubs, it really can prevent the introduction of bugs without being overly brittle.

[rufugee]

So would the appropriate approach in this case be to create IForum, ITopic and IPost interfaces and, instead of calling findAll() or count() directly on the class, call it on the interface so a class can be injected? Sorry...this is all a bit hazy to me. It's been years since I've had to deal with these sorts of concerns.

[latch]

Something like that..but then the question is: how do you get the instance in there? Normally through DI (ideally at the constructor level)...but the static method screws that up.

I agree that worrying about this is silly, but such is the life of someone who uses static languages.

[sixbrx]

What you're complaining about is just the data access which happens to be used in this sample (particularly some convenience methods which aren't even necessary), which you can freely change out with any technology that you please, because it's completely orthogonal to the rest of the framework. The framework has no abstractions over or requirements for the data access framework.

Or without even changing the data access calls you could just put them behind a DAO object, which would have been injected and therefore easily replaced for testing. But that wouldn't have made the sample any clearer.

[wiradikusuma]

I use PowerMock with Mockito for this kind of thing.

[pk11]

well, that's for play 1.

[soc88]

This looks pretty much like standard JPA stuff.

[brown9-2]

I don't think JPA requires or encourages you to use static methods.