Live data from Hacker News

Play Framework 2.0 Final released

playframework.org

11–20 of 61 posts

Re: Play Framework 2.0 Final released

#11
post #4

When I did a bit of Play 1.2 dev, I ran into two serious annoyances. First, static actions make for untestable code. The only way to test this in 1.2 was to do full integration tests. You can't unit test controllers/actions, which to me is a horrible "opinion" to have. Looking at the docs, 2.0 [appears] to make an attempt via the callAction helper [1], but you still can't inject dependencies via a constructor and cal…

I agree about the testing. It is also really annoying that you can't run a test as a "single, isolated test". I read a few articles on Play 2.0 and Scala, but haven't come across any additions on testing. Without decent testing integrated, this framework has no real production use. I agree that it all looks nice and shiny though.

Re: Play Framework 2.0 Final released

#12
post #4

When I did a bit of Play 1.2 dev, I ran into two serious annoyances. First, static actions make for untestable code. The only way to test this in 1.2 was to do full integration tests. You can't unit test controllers/actions, which to me is a horrible "opinion" to have. Looking at the docs, 2.0 [appears] to make an attempt via the callAction helper [1], but you still can't inject dependencies via a constructor and cal…

I don't understand why you would want static methods everywhere in this age of dependency injection everywhere.

Re: Play Framework 2.0 Final released

#13
I am really excited about this but also a bit worried that Java will become a second class citizen for Play development.

The typesafe deal, use of SBT and other scala tools, and the overhead of maintaining docs and bindings for 2 languages all seems to point to an inevitable deprecation of Java at some point.

Hopefully not?

Re: Play Framework 2.0 Final released

#14
Their beta was incredibly buggy, riddled with compilation performance performance, slow load times, was really not a fun experience. I've heard they finally got development load times in check. I hope they get their deployment process a bit better then creating a zip file and having to run nohup on their start script.

Re: Play Framework 2.0 Final released

#15
post #4

When I did a bit of Play 1.2 dev, I ran into two serious annoyances. First, static actions make for untestable code. The only way to test this in 1.2 was to do full integration tests. You can't unit test controllers/actions, which to me is a horrible "opinion" to have. Looking at the docs, 2.0 [appears] to make an attempt via the callAction helper [1], but you still can't inject dependencies via a constructor and cal…

Can you elaborate more on the untestable code point, for those of us who've been spending more time on ruby lately? I find play very interesting, but it's great to hear about its warts as well.

Re: Play Framework 2.0 Final released

#16
post #15
post #4

When I did a bit of Play 1.2 dev, I ran into two serious annoyances. First, static actions make for untestable code. The only way to test this in 1.2 was to do full integration tests. You can't unit test controllers/actions, which to me is a horrible "opinion" to have. Looking at the docs, 2.0 [appears] to make an attempt via the callAction helper [1], but you still can't inject dependencies via a constructor and cal…

Can you elaborate more on the untestable code point, for those of us who've been spending more time on ruby lately? I find play very interesting, but it's great to hear about its warts as well.

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...

Re: Play Framework 2.0 Final released

#17
post #16
post #15

Earlier quoted context omitted.

Can you elaborate more on the untestable code point, for those of us who've been spending more time on ruby lately? I find play very interesting, but it's great to hear about its warts as well.

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 con…

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.

Re: Play Framework 2.0 Final released

#18
post #17
post #16

Earlier quoted context omitted.

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 con…

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.

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.

Re: Play Framework 2.0 Final released

#19
post #16
post #15

Earlier quoted context omitted.

Can you elaborate more on the untestable code point, for those of us who've been spending more time on ruby lately? I find play very interesting, but it's great to hear about its warts as well.

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 con…

This looks pretty much like standard JPA stuff.

Re: Play Framework 2.0 Final released

#20
post #13

I am really excited about this but also a bit worried that Java will become a second class citizen for Play development. The typesafe deal, use of SBT and other scala tools, and the overhead of maintaining docs and bindings for 2 languages all seems to point to an inevitable deprecation of Java at some point. Hopefully not?

Why would it be bad?
Post reply on HN