Play! Framework FakeApplication - What does it actually do?
I realize that you asked this over a year ago, but it took me quite some time to figure this out for myself, so hopefully this helps someone at some point.
With a FakeApplication running, you can do basically everything you can after saying "activator run", except that there is not a webserver (netty) running serving up requests. You can though, test your controllers, as shown here, and call methods that access the database.
I actually referenced both of those posts you mention when figuring this out, in addition to this one, which discusses some special play magic config vars that must be set you'll see in my example below.
I created an abstract FakeApplicationTest class which I extend in the Unit/Functional tests. I first use my existing application.conf file, then overwrite certain parameters to test against a different database. Once the FakeApplication is started, I read in all the evolutions and create a fresh database to run my tests against.
public abstract class FakeApplicationTest { protected static FakeApplication app; /** * Create a new FakeApplication using all our custom config vars that test against diff DB's * * @return */ public static FakeApplication createFakeApp() { // grab the main application.conf file that is used to start up the Play application Config config = ConfigFactory.parseFile(new File("conf/application.conf")); // resolve all variables within this config file with other variables within itself config = ConfigFactory.load(config); // create a Configuration object out of this and then turn it into a Map to be modified Configuration configuration = new Configuration(config); Map<String, Object> fakeApplicationConf = Maps.newHashMap(configuration.asMap()); // do some crazy stuff here because Play wants us to for config voodoo, see: // http://www.stupidjavatricks.com/2013/05/changing-play-2-db-configuration-at-runtime-beware-of-dragons/ Configuration akka = configuration.getConfig("akka.actor.serialization-bindings"); addValue(fakeApplicationConf, "akka.actor.serialization-bindings", null); addValue(fakeApplicationConf, "akka.actor.serialization-bindings.\"[B\"", akka.getString("\"[\"B")); addValue(fakeApplicationConf, "akka.actor.serialization-bindings.\"java.io.Serializable\"", akka.getString("\"java.io.Serializable\"")); // point at a different test database addValue(fakeApplicationConf, "db.default.url", "jdbc:mysql://127.0.0.1/testdb"); addValue(fakeApplicationConf, "db.default.user", "someuser"); addValue(fakeApplicationConf, "db.default.password", "hunter2"); // disable evolutions and just create the DB manually addValue(fakeApplicationConf, "evolutionplugin", "disabled"); return Helpers.fakeApplication(fakeApplicationConf); } @BeforeClass public static void setUp() throws Exception { app = createFakeApp(); // fire up the Fake Application! Helpers.start(app); // after we start up the application, create a database createCleanDb(); } @AfterClass public static void tearDown() throws Exception { Helpers.stop(app); } ...}
There is quite a bit to reading out the evolutions and applying them in order too, but I've left that out for now.