Running the lift init lifecycle in sbt test

[Flav Alex]

Is there a way of manually running the lift initialisation lifecycle during sbt:test without having an actual webapp running? More than often we rely heavily on things like Props configuration, Lift modes and other core primitives to get stuff done, and in sbt:test it all goes wrong as Lift hasn't computed the running mode.

I would imagine there's a lot more context to the lifecycle than it's immediately visible, however is there a simple Lift.manualBoot?

Or is there a way to make sbt:test depend on container:start or something like that?

[Matt Farmer]

Hi Flav,

So I’m going to put on my “opinionated programmer hat” for a minute and say that if you find yourself thinking “I need test to depend on container:start” that you’ll probably find dragons waiting for you down the road. You can create that interdependency, but it comes with a bucket load of other behavior and probably won’t actually do what you want. That’s a gut feeling, so take it with that grain of salt.

First, it sounds weird that Lift wouldn’t have a running mode available. The sbt test runner should be setting run.mode to test for those tests.

I’d suggest some combination of the following:

Put the props you need under src/test/resources. I’ve seen cases where src/main/resources isn’t pulled into unit tests as I expect it to be, so perhaps putting a props file under src/test/resources will do what you need in this particular example? Also try using the filename test.default.props instead of one of the other variations.

Looking at whether or not mockweb will give you want you want. Not having statefulness in a test is the most common reason I see people asking to have test depend on container:start. The net.liftweb.mockweb package allows you to stub out an instance of S and then run some code in that context. So you can run things that require statefulness without booting the entire framework. So you might write something like:

My usual combination looks something like:

testReq(“/users/1”) { req =>

  testS(req) {

    // run code that requires statefulness

  }

}

Potentially, run part of your Boot class before your tests run. I’ve done some projects where there is some, but not complete, overlaps between things I need to happen before my tests run and things that need to happen before the user can interact with my app. In those cases, I’ve sometimes put a second boot method in my Boot class:

class Boot {

  def thingsNeededForTests = {

    // Things needed for test and live execution

  }

  def boot = {

    thingsNeededForTests()

    // Other things

  }

}

Of course, choose a better name than I did above. ;)

If none of these work, please feel free to push an example project to GitHub that doesn’t behave how you want it to and I can spend a little bit of time playing with it to see if I can get it working.

Cheers,

—
Matt Farmer | Blog | Twitter

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Flav Alex]

Hi Matt,

Many thanks for pointing out the test behaviour, it seems all I really needed was a very simple addition for Props.testMode

Now everything is working as expected.

Regards,

[Matt Farmer]

Glad to hear it!

—
Matt Farmer | Blog | Twitter