<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Observations on the Play! framework</title>
	<atom:link href="http://lostechies.com/jamesgregory/2011/09/18/observations-on-the-play-framework/feed/" rel="self" type="application/rss+xml" />
	<link>http://lostechies.com/jamesgregory/2011/09/18/observations-on-the-play-framework/</link>
	<description>Just another LosTechies site</description>
	<lastBuildDate>Thu, 21 Feb 2013 18:09:00 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.4.2</generator>
	<item>
		<title>By: Ashish</title>
		<link>http://lostechies.com/jamesgregory/2011/09/18/observations-on-the-play-framework/#comment-147</link>
		<dc:creator>Ashish</dc:creator>
		<pubDate>Thu, 21 Feb 2013 18:09:00 +0000</pubDate>
		<guid isPermaLink="false">http://lostechies.com/jamesgregory/?p=37#comment-147</guid>
		<description>I am fairly new to Play, but seems very difficult to do DI. I am not able to get the confidence in doing TDD in Play</description>
		<content:encoded><![CDATA[<p>I am fairly new to Play, but seems very difficult to do DI. I am not able to get the confidence in doing TDD in Play</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Hesson</title>
		<link>http://lostechies.com/jamesgregory/2011/09/18/observations-on-the-play-framework/#comment-145</link>
		<dc:creator>David Hesson</dc:creator>
		<pubDate>Sat, 29 Sep 2012 20:16:00 +0000</pubDate>
		<guid isPermaLink="false">http://lostechies.com/jamesgregory/?p=37#comment-145</guid>
		<description>Has this changed much at all in Play?  My suspicions after toying with Play 2.0 this morning were that testing was going to be annoying, especially isolation unit tests that I want to run fast, without services running.  Seems like this post confirms my fears.  I also see plenty of stack overflow posts mentioning that DI is unnecessary in Play  but I think people forget that well laid out services/controllers rely on interfaces and class composition to perform work, which invites DI and makes it easier to unit test this code as well as configure your application.</description>
		<content:encoded><![CDATA[<p>Has this changed much at all in Play?  My suspicions after toying with Play 2.0 this morning were that testing was going to be annoying, especially isolation unit tests that I want to run fast, without services running.  Seems like this post confirms my fears.  I also see plenty of stack overflow posts mentioning that DI is unnecessary in Play  but I think people forget that well laid out services/controllers rely on interfaces and class composition to perform work, which invites DI and makes it easier to unit test this code as well as configure your application.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Samario</title>
		<link>http://lostechies.com/jamesgregory/2011/09/18/observations-on-the-play-framework/#comment-142</link>
		<dc:creator>Samario</dc:creator>
		<pubDate>Thu, 19 Jan 2012 21:52:00 +0000</pubDate>
		<guid isPermaLink="false">http://lostechies.com/jamesgregory/?p=37#comment-142</guid>
		<description>Hello James,

Five years ago you shared this knowledge &lt;&gt;, I don´t know how to implemented it, Can you please share a complete implementation, that is to say, a little visual studio project using the code.  I will be gratefull for your help. Thansk. Henry.-

My email is : samario@gmail.com.</description>
		<content:encoded><![CDATA[<p>Hello James,</p>
<p>Five years ago you shared this knowledge &lt;&gt;, I don´t know how to implemented it, Can you please share a complete implementation, that is to say, a little visual studio project using the code.  I will be gratefull for your help. Thansk. Henry.-</p>
<p>My email is : <a href="mailto:samario@gmail.com">samario@gmail.com</a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Royston Shufflebotham</title>
		<link>http://lostechies.com/jamesgregory/2011/09/18/observations-on-the-play-framework/#comment-132</link>
		<dc:creator>Royston Shufflebotham</dc:creator>
		<pubDate>Sun, 30 Oct 2011 17:08:00 +0000</pubDate>
		<guid isPermaLink="false">http://lostechies.com/jamesgregory/?p=37#comment-132</guid>
		<description>I&#039;ve always subscribed to the notion that a framework API shouldn&#039;t be considered as having &#039;survived contact with the enemy&#039; until not only has somebody written something using your API, but that they have also written tests against their code.

I&#039;ve just started getting into Play, having previously used ASP.NET MVC and Rails, and having spent the last few years doing constructor-based injection testing, it&#039;s  bit of a disappointment testing-wise. Didn&#039;t they learn from the static unmockable HttpContent fiasco in ASP.NET? *sigh*

But maybe it&#039;s not a &#039;deal breaker&#039; - can we make it work anyway?

Controller action methods are meant to be extremely lightweight, and generally you want to get out of those and into services, repositories, other (non-REST) &#039;controller&#039; objects as quickly as possible.  Those can all be developed using proper instances with constructor injection and all the usual good stuff, no?

Play introduces its own &#039;FunctionalTest&#039; and &#039;UnitTest&#039; base classes, but you don&#039;t have to use them: you can write your own (fast) plain JUnit tests as long as the code you&#039;re testing doesn&#039;t make heavy use of Play stuff, which is probably in the database level.  But then you&#039;re straying out of unit tests and into more integration-y tests, perhaps?  The biggest area of irritation there is all the static fields inherited from Controller, e.g. &#039;validation&#039;.

I dunno.  I like the feel of the framework (apart from the curious static methods everywhere) and so I _want_ it to work.  But when I see the great work that&#039;s been going on in ASP.NET MVC, where they&#039;ve made it really easy to use out-of-the-box yet have made everything completely pluggable and testable, Play seems a bit backward.

I&#039;m going to give it a try and see if I can bend it to my DI+unit testing will.  If not, I&#039;m dumping it.  But what&#039;s the alternative in Java land? :(

</description>
		<content:encoded><![CDATA[<p>I&#8217;ve always subscribed to the notion that a framework API shouldn&#8217;t be considered as having &#8216;survived contact with the enemy&#8217; until not only has somebody written something using your API, but that they have also written tests against their code.</p>
<p>I&#8217;ve just started getting into Play, having previously used ASP.NET MVC and Rails, and having spent the last few years doing constructor-based injection testing, it&#8217;s  bit of a disappointment testing-wise. Didn&#8217;t they learn from the static unmockable HttpContent fiasco in ASP.NET? *sigh*</p>
<p>But maybe it&#8217;s not a &#8216;deal breaker&#8217; &#8211; can we make it work anyway?</p>
<p>Controller action methods are meant to be extremely lightweight, and generally you want to get out of those and into services, repositories, other (non-REST) &#8216;controller&#8217; objects as quickly as possible.  Those can all be developed using proper instances with constructor injection and all the usual good stuff, no?</p>
<p>Play introduces its own &#8216;FunctionalTest&#8217; and &#8216;UnitTest&#8217; base classes, but you don&#8217;t have to use them: you can write your own (fast) plain JUnit tests as long as the code you&#8217;re testing doesn&#8217;t make heavy use of Play stuff, which is probably in the database level.  But then you&#8217;re straying out of unit tests and into more integration-y tests, perhaps?  The biggest area of irritation there is all the static fields inherited from Controller, e.g. &#8216;validation&#8217;.</p>
<p>I dunno.  I like the feel of the framework (apart from the curious static methods everywhere) and so I _want_ it to work.  But when I see the great work that&#8217;s been going on in ASP.NET MVC, where they&#8217;ve made it really easy to use out-of-the-box yet have made everything completely pluggable and testable, Play seems a bit backward.</p>
<p>I&#8217;m going to give it a try and see if I can bend it to my DI+unit testing will.  If not, I&#8217;m dumping it.  But what&#8217;s the alternative in Java land? <img src='http://lostechies.com/jamesgregory/wp-includes/images/smilies/icon_sad.gif' alt=':(' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous</title>
		<link>http://lostechies.com/jamesgregory/2011/09/18/observations-on-the-play-framework/#comment-130</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Sun, 25 Sep 2011 16:03:00 +0000</pubDate>
		<guid isPermaLink="false">http://lostechies.com/jamesgregory/?p=37#comment-130</guid>
		<description>Hi Ryan, you are correct. I do actually do this, though re-reading what I wrote I can see how that&#039;s not very clear. My real complaint is that whilst you can run them in your IDE, they require the full web stack to be available before they&#039;ll execute; this basically means you get a minimum of a 5s overhead for running your tests. Five seconds doesn&#039;t sound like much, I admit, but it quickly gets frustrating when you&#039;re used to a fast cycle.

Like many things in Play, I can live with it, and I can appreciate their decisions; however, it would be nice to not *have* to do it their way. I get the feeling Play! is at the place where Rails was a few years ago.

Phase 1: &quot;You WILL do it our way!&quot;
Phase 2: &quot;Ok, you SHOULD do it our way but you can deviate a bit&quot;
Phase 3: &quot;Our way is the default, do whatever the hell you want though.&quot;</description>
		<content:encoded><![CDATA[<p>Hi Ryan, you are correct. I do actually do this, though re-reading what I wrote I can see how that&#8217;s not very clear. My real complaint is that whilst you can run them in your IDE, they require the full web stack to be available before they&#8217;ll execute; this basically means you get a minimum of a 5s overhead for running your tests. Five seconds doesn&#8217;t sound like much, I admit, but it quickly gets frustrating when you&#8217;re used to a fast cycle.</p>
<p>Like many things in Play, I can live with it, and I can appreciate their decisions; however, it would be nice to not *have* to do it their way. I get the feeling Play! is at the place where Rails was a few years ago.</p>
<p>Phase 1: &#8220;You WILL do it our way!&#8221;<br />
Phase 2: &#8220;Ok, you SHOULD do it our way but you can deviate a bit&#8221;<br />
Phase 3: &#8220;Our way is the default, do whatever the hell you want though.&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ryan Svihla</title>
		<link>http://lostechies.com/jamesgregory/2011/09/18/observations-on-the-play-framework/#comment-129</link>
		<dc:creator>Ryan Svihla</dc:creator>
		<pubDate>Sun, 25 Sep 2011 15:21:00 +0000</pubDate>
		<guid isPermaLink="false">http://lostechies.com/jamesgregory/?p=37#comment-129</guid>
		<description>It&#039;s been awhile since I&#039;ve been in the Java space but I seem to remember being able to run tests through Intellij when using the play &quot;idealize&quot; command see the following link

http://www.playframework.org/documentation/1.2.3/ide </description>
		<content:encoded><![CDATA[<p>It&#8217;s been awhile since I&#8217;ve been in the Java space but I seem to remember being able to run tests through Intellij when using the play &#8220;idealize&#8221; command see the following link</p>
<p><a href="http://www.playframework.org/documentation/1.2.3/ide " rel="nofollow">http://www.playframework.org/documentation/1.2.3/ide </a></p>
]]></content:encoded>
	</item>
</channel>
</rss>
