You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@esme.apache.org by David Pollak <fe...@gmail.com> on 2009/11/11 01:04:31 UTC
Not a lot of ESME output from me today
Folks,
I started writing some ESME tests and got very cranky with Lift's TestKit
(what kind of fool wrote those APIs anyway... oh, look, here's a mirror and
I'm looking at the fool).
I spent a couple of hours cleaning up the Lift TestKit APIs so that tests
will look like:
"Login" in {
for{
login <- post("/api/login", "token" -> token) !@ "Failed to log in"
if (testSuccess(login))
status <- login.get("/api/status") !@ "Failed to get status" if
(testSuccess(status))
} {
(status.xml \ "user" \ "@id").text must_== theUser.id.toString
}
}
Once the Lift changes get approved and propagated, I'll post up the new API
test code.
I plan to spend more time in ESME-land on Thursday and will get some of the
user edit and OpenID stuff finished.
Thanks,
David
PS -- What's the ETA for the new templates?
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
Re: Not a lot of ESME output from me today
Posted by Richard Hirsch <hi...@gmail.com>.
@Ethan: Why shouldn't the full test run. This is perfect for the
Hudosn-based environment. I think it would better to have some sort of
a maven flag that allows you to run your tests but not the whole test
suite. No idea how this might work, because I'm not a maven expert.
D.
On Fri, Nov 13, 2009 at 3:50 PM, Ethan Jewett <es...@gmail.com> wrote:
> Hi,
>
> It looks like these tests got checked in even though they don't run as
> yet. Can they be commented out until they are operational? Currently
> they are causing the full test run to fail, which is not the end of
> the world but is something we should probably avoid.
>
> Ethan
>
> On Tue, Nov 10, 2009 at 7:04 PM, David Pollak
> <fe...@gmail.com> wrote:
>> Folks,
>>
>> I started writing some ESME tests and got very cranky with Lift's TestKit
>> (what kind of fool wrote those APIs anyway... oh, look, here's a mirror and
>> I'm looking at the fool).
>>
>> I spent a couple of hours cleaning up the Lift TestKit APIs so that tests
>> will look like:
>>
>> "Login" in {
>> for{
>> login <- post("/api/login", "token" -> token) !@ "Failed to log in"
>> if (testSuccess(login))
>> status <- login.get("/api/status") !@ "Failed to get status" if
>> (testSuccess(status))
>> } {
>> (status.xml \ "user" \ "@id").text must_== theUser.id.toString
>> }
>> }
>>
>> Once the Lift changes get approved and propagated, I'll post up the new API
>> test code.
>>
>> I plan to spend more time in ESME-land on Thursday and will get some of the
>> user edit and OpenID stuff finished.
>>
>> Thanks,
>>
>> David
>>
>> PS -- What's the ETA for the new templates?
>>
>>
>> --
>> Lift, the simply functional web framework http://liftweb.net
>> Beginning Scala http://www.apress.com/book/view/1430219890
>> Follow me: http://twitter.com/dpp
>> Surf the harmonics
>>
>
Re: Not a lot of ESME output from me today
Posted by Vassil Dichev <vd...@apache.org>.
> With regard to running tests on Hudson, I think failing tests are
> perfect, but the tests need to run through without exceptions (they
> can fail, but they can't have uncaught exceptions ... I think) or they
> will severely reduce the usability of the test suite and of the Hudson
> integration. Is that right?
The result of a test can be an explicit failure (assertion) or an
error (exception). Both of these mean the same thing- the test does
not pass with OK!
In this case, the port the test is trying to open, is already open by
some other process. This could even be the same test suite if there
are more than one Jetty instance started by several tests.
Re: Not a lot of ESME output from me today
Posted by Ethan Jewett <es...@gmail.com>.
Vassil,
Yeah, it's not the same error. My mistake for not checking the actual
Hudson error message. That complicates the whole matter. I'm actually
getting a complete build failure when I do "mvn test", which I think
is due only to the test failures. When I do "mvn jetty:run", it's
fine.
The other thing to keep in mind is that my local repo is out of sync
with the main one, so take what errors I have with a really huge cube
of salt for the time being. It's possible that the issue with the main
API tests will go away once I sync up.
Ethan
On Fri, Nov 13, 2009 at 1:44 PM, Vassil Dichev <vd...@apache.org> wrote:
>> That's fair, but something is wrong, because this exception is
>> resulting in no test results at all (on either my system or on
>> Hudson). It's as if the test runner doesn't catch the exception and
>> instead of converting it to a test failure it just gives up on the
>> whole test suite.
>>
>> If the new API test is failing, I'd expect to see 21 passed tests and
>> 1 failed, but instead it's as if there were no tests at all.
>
> You're right, I assumed your error is the same as the one on hudson.
> The success message is also strange, but I think this depends on the
> maven configuration- we could set it up so that the whole build fails
> if tests fail (and we should).
>
> As for the message now on hudson, I remember seeing it in the past-
> only on the mailing list though. Do you remember what solved it?
>
> http://mail-archives.apache.org/mod_mbox/incubator-esme-dev/200906.mbox/%3C48d391a20906282007p5f0159e8x1c4500482e281aa7@mail.gmail.com%3E
>
Re: Not a lot of ESME output from me today
Posted by Vassil Dichev <vd...@apache.org>.
> That's fair, but something is wrong, because this exception is
> resulting in no test results at all (on either my system or on
> Hudson). It's as if the test runner doesn't catch the exception and
> instead of converting it to a test failure it just gives up on the
> whole test suite.
>
> If the new API test is failing, I'd expect to see 21 passed tests and
> 1 failed, but instead it's as if there were no tests at all.
You're right, I assumed your error is the same as the one on hudson.
The success message is also strange, but I think this depends on the
maven configuration- we could set it up so that the whole build fails
if tests fail (and we should).
As for the message now on hudson, I remember seeing it in the past-
only on the mailing list though. Do you remember what solved it?
http://mail-archives.apache.org/mod_mbox/incubator-esme-dev/200906.mbox/%3C48d391a20906282007p5f0159e8x1c4500482e281aa7@mail.gmail.com%3E
Re: Not a lot of ESME output from me today
Posted by Ethan Jewett <es...@gmail.com>.
Vassil,
That's fair, but something is wrong, because this exception is
resulting in no test results at all (on either my system or on
Hudson). It's as if the test runner doesn't catch the exception and
instead of converting it to a test failure it just gives up on the
whole test suite.
If the new API test is failing, I'd expect to see 21 passed tests and
1 failed, but instead it's as if there were no tests at all.
Dick,
Yup, I'm going to be sending you a new patch with that and other
updates, hopefully this weekend. It looks like David or Vassil already
factored out the JettyTestServer object that was causing the problem,
so I just need to delete it from my API tests.
Ethan
On Fri, Nov 13, 2009 at 1:20 PM, Richard Hirsch <hi...@gmail.com> wrote:
> If you look at the console message from the last build
> (http://hudson.zones.apache.org/hudson/job/ESME/lastBuild/console),
> you do a see an error but a different one than Ethan mentioned. What
> is strange is that I have never seen this error during my local
> builds.
>
> Even stranger is that Hudson says the test was successful.
>
> If you look at the difference between build 4
> (http://hudson.zones.apache.org/hudson/job/ESME/4/console) and 5
> (http://hudson.zones.apache.org/hudson/job/ESME/5/console), you will
> see that the exceptions come with the changes that occurred between 4
> and 5. According to Hudson
> (http://hudson.zones.apache.org/hudson/job/ESME/5/), the only changes
> were David's new test cases. What is weird is that the exceptions
> occur in the MsgParserSpecsAsTest where no changes occured.
>
> The exception is below.
>
> @Ethan: By the way, I haven't checked in your API tests, because of
> the problems mentioned in my email from Nov. 9
>
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running org.apache.esme.AppTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.07 sec
> Running org.apache.esme.lib.MsgParserSpecsAsTest
> 2009-11-13 12:23:37.902::INFO: Logging to STDERR via org.mortbay.log.StdErrLog
> 2009-11-13 12:23:37.969::INFO: jetty-6.1.21
> 2009-11-13 12:23:38.036::INFO: Started SocketConnector@0.0.0.0:8989
> org.apache.maven.surefire.booter.SurefireExecutionException: null;
> nested exception is java.lang.ExceptionInInitializerError: null
> java.lang.ExceptionInInitializerError
> at org.apache.esme.lib.MsgParserSpecsAsTest.<init>(MsgParseTest.scala:44)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at org.specs.runner.JUnitSuiteRunner.testSuite(JUnitSuiteRunner.scala:37)
> at org.specs.runner.JUnitSuiteRunner.run(JUnitSuiteRunner.scala:45)
> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
> at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)
> Caused by: java.lang.NullPointerException: Looking for Connection
> Identifier ConnectionIdentifier(lift) but failed to find either a JNDI
> data source with the name lift or a lift connection manager with the
> correct name
>
>
>
> On Fri, Nov 13, 2009 at 7:03 PM, Ethan Jewett <es...@gmail.com> wrote:
>> When I do "mvn test" on my system, it bails out. The error message is
>> below. It looks to me like it is not working on Hudson either, if you
>> look at the test results trend on the following page:
>> http://hudson.zones.apache.org/hudson/job/ESME/
>>
>> With regard to running tests on Hudson, I think failing tests are
>> perfect, but the tests need to run through without exceptions (they
>> can fail, but they can't have uncaught exceptions ... I think) or they
>> will severely reduce the usability of the test suite and of the Hudson
>> integration. Is that right?
>>
>> Thanks,
>> Ethan
>>
>> Error from my system:
>>
>> 2009-11-13 13:00:38.505::WARN: failed SocketConnector@0.0.0.0:8989:
>> java.net.BindException: Address already in use
>> 2009-11-13 13:00:38.505::WARN: failed Server@65861e41:
>> java.net.BindException: Address already in use
>> org.apache.maven.surefire.booter.SurefireExecutionException: null;
>> nested exception is java.lang.ExceptionInInitializerError: null
>> java.lang.ExceptionInInitializerError
>> at org.apache.esme.api.ApiSpecsAsTest.<init>(ApiTest.scala:43)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>> at java.lang.Class.newInstance0(Class.java:355)
>> at java.lang.Class.newInstance(Class.java:308)
>> at org.specs.runner.JUnitSuiteRunner.testSuite(JUnitSuiteRunner.scala:37)
>> at org.specs.runner.JUnitSuiteRunner.run(JUnitSuiteRunner.scala:45)
>> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
>> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
>> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
>> at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
>> at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)
>> Caused by: java.net.BindException: Address already in use
>> at java.net.PlainSocketImpl.socketBind(Native Method)
>> at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
>> at java.net.ServerSocket.bind(ServerSocket.java:319)
>> at java.net.ServerSocket.<init>(ServerSocket.java:185)
>> at java.net.ServerSocket.<init>(ServerSocket.java:141)
>> at org.mortbay.jetty.bio.SocketConnector.newServerSocket(SocketConnector.java:80)
>> at org.mortbay.jetty.bio.SocketConnector.open(SocketConnector.java:73)
>> at org.mortbay.jetty.AbstractConnector.doStart(AbstractConnector.java:283)
>> at org.mortbay.jetty.bio.SocketConnector.doStart(SocketConnector.java:147)
>> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>> at org.mortbay.jetty.Server.doStart(Server.java:235)
>> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>> at org.apache.esme.JettyTestServer$.start(JettySetup.scala:64)
>> at org.apache.esme.api.ApiSpecs$.<init>(ApiTest.scala:47)
>> at org.apache.esme.api.ApiSpecs$.<clinit>(ApiTest.scala)
>> ... 19 more
>> [INFO] ------------------------------------------------------------------------
>> [ERROR] BUILD FAILURE
>> [INFO] ------------------------------------------------------------------------
>> [INFO] There are test failures.
>>
>> Please refer to
>> /Users/esjewett/svn_repos/esme/trunk/server/target/surefire-reports
>> for the individual test results.
>>
>>
>> On Fri, Nov 13, 2009 at 11:32 AM, David Pollak
>> <fe...@gmail.com> wrote:
>>> On Fri, Nov 13, 2009 at 6:50 AM, Ethan Jewett <es...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> It looks like these tests got checked in even though they don't run as
>>>> yet. Can they be commented out until they are operational? Currently
>>>> they are causing the full test run to fail, which is not the end of
>>>> the world but is something we should probably avoid.
>>>>
>>>
>>> The code I checked into the ESME SVN repo does run.
>>>
>>> If there is a problem running these tests, please let me know what the
>>> output is.
>>>
>>>
>>>>
>>>> Ethan
>>>>
>>>> On Tue, Nov 10, 2009 at 7:04 PM, David Pollak
>>>> <fe...@gmail.com> wrote:
>>>> > Folks,
>>>> >
>>>> > I started writing some ESME tests and got very cranky with Lift's TestKit
>>>> > (what kind of fool wrote those APIs anyway... oh, look, here's a mirror
>>>> and
>>>> > I'm looking at the fool).
>>>> >
>>>> > I spent a couple of hours cleaning up the Lift TestKit APIs so that tests
>>>> > will look like:
>>>> >
>>>> > "Login" in {
>>>> > for{
>>>> > login <- post("/api/login", "token" -> token) !@ "Failed to log
>>>> in"
>>>> > if (testSuccess(login))
>>>> > status <- login.get("/api/status") !@ "Failed to get status" if
>>>> > (testSuccess(status))
>>>> > } {
>>>> > (status.xml \ "user" \ "@id").text must_== theUser.id.toString
>>>> > }
>>>> > }
>>>> >
>>>> > Once the Lift changes get approved and propagated, I'll post up the new
>>>> API
>>>> > test code.
>>>> >
>>>> > I plan to spend more time in ESME-land on Thursday and will get some of
>>>> the
>>>> > user edit and OpenID stuff finished.
>>>> >
>>>> > Thanks,
>>>> >
>>>> > David
>>>> >
>>>> > PS -- What's the ETA for the new templates?
>>>> >
>>>> >
>>>> > --
>>>> > Lift, the simply functional web framework http://liftweb.net
>>>> > Beginning Scala http://www.apress.com/book/view/1430219890
>>>> > Follow me: http://twitter.com/dpp
>>>> > Surf the harmonics
>>>> >
>>>>
>>>
>>>
>>>
>>> --
>>> Lift, the simply functional web framework http://liftweb.net
>>> Beginning Scala http://www.apress.com/book/view/1430219890
>>> Follow me: http://twitter.com/dpp
>>> Surf the harmonics
>>>
>>
>
Re: Not a lot of ESME output from me today
Posted by Richard Hirsch <hi...@gmail.com>.
Sorry just checked, there was a change in MsgParserSpecsAsTest file.
D.
On Fri, Nov 13, 2009 at 7:20 PM, Richard Hirsch <hi...@gmail.com> wrote:
> If you look at the console message from the last build
> (http://hudson.zones.apache.org/hudson/job/ESME/lastBuild/console),
> you do a see an error but a different one than Ethan mentioned. What
> is strange is that I have never seen this error during my local
> builds.
>
> Even stranger is that Hudson says the test was successful.
>
> If you look at the difference between build 4
> (http://hudson.zones.apache.org/hudson/job/ESME/4/console) and 5
> (http://hudson.zones.apache.org/hudson/job/ESME/5/console), you will
> see that the exceptions come with the changes that occurred between 4
> and 5. According to Hudson
> (http://hudson.zones.apache.org/hudson/job/ESME/5/), the only changes
> were David's new test cases. What is weird is that the exceptions
> occur in the MsgParserSpecsAsTest where no changes occured.
>
> The exception is below.
>
> @Ethan: By the way, I haven't checked in your API tests, because of
> the problems mentioned in my email from Nov. 9
>
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running org.apache.esme.AppTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.07 sec
> Running org.apache.esme.lib.MsgParserSpecsAsTest
> 2009-11-13 12:23:37.902::INFO: Logging to STDERR via org.mortbay.log.StdErrLog
> 2009-11-13 12:23:37.969::INFO: jetty-6.1.21
> 2009-11-13 12:23:38.036::INFO: Started SocketConnector@0.0.0.0:8989
> org.apache.maven.surefire.booter.SurefireExecutionException: null;
> nested exception is java.lang.ExceptionInInitializerError: null
> java.lang.ExceptionInInitializerError
> at org.apache.esme.lib.MsgParserSpecsAsTest.<init>(MsgParseTest.scala:44)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at org.specs.runner.JUnitSuiteRunner.testSuite(JUnitSuiteRunner.scala:37)
> at org.specs.runner.JUnitSuiteRunner.run(JUnitSuiteRunner.scala:45)
> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
> at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)
> Caused by: java.lang.NullPointerException: Looking for Connection
> Identifier ConnectionIdentifier(lift) but failed to find either a JNDI
> data source with the name lift or a lift connection manager with the
> correct name
>
>
>
> On Fri, Nov 13, 2009 at 7:03 PM, Ethan Jewett <es...@gmail.com> wrote:
>> When I do "mvn test" on my system, it bails out. The error message is
>> below. It looks to me like it is not working on Hudson either, if you
>> look at the test results trend on the following page:
>> http://hudson.zones.apache.org/hudson/job/ESME/
>>
>> With regard to running tests on Hudson, I think failing tests are
>> perfect, but the tests need to run through without exceptions (they
>> can fail, but they can't have uncaught exceptions ... I think) or they
>> will severely reduce the usability of the test suite and of the Hudson
>> integration. Is that right?
>>
>> Thanks,
>> Ethan
>>
>> Error from my system:
>>
>> 2009-11-13 13:00:38.505::WARN: failed SocketConnector@0.0.0.0:8989:
>> java.net.BindException: Address already in use
>> 2009-11-13 13:00:38.505::WARN: failed Server@65861e41:
>> java.net.BindException: Address already in use
>> org.apache.maven.surefire.booter.SurefireExecutionException: null;
>> nested exception is java.lang.ExceptionInInitializerError: null
>> java.lang.ExceptionInInitializerError
>> at org.apache.esme.api.ApiSpecsAsTest.<init>(ApiTest.scala:43)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>> at java.lang.Class.newInstance0(Class.java:355)
>> at java.lang.Class.newInstance(Class.java:308)
>> at org.specs.runner.JUnitSuiteRunner.testSuite(JUnitSuiteRunner.scala:37)
>> at org.specs.runner.JUnitSuiteRunner.run(JUnitSuiteRunner.scala:45)
>> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
>> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
>> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
>> at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
>> at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)
>> Caused by: java.net.BindException: Address already in use
>> at java.net.PlainSocketImpl.socketBind(Native Method)
>> at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
>> at java.net.ServerSocket.bind(ServerSocket.java:319)
>> at java.net.ServerSocket.<init>(ServerSocket.java:185)
>> at java.net.ServerSocket.<init>(ServerSocket.java:141)
>> at org.mortbay.jetty.bio.SocketConnector.newServerSocket(SocketConnector.java:80)
>> at org.mortbay.jetty.bio.SocketConnector.open(SocketConnector.java:73)
>> at org.mortbay.jetty.AbstractConnector.doStart(AbstractConnector.java:283)
>> at org.mortbay.jetty.bio.SocketConnector.doStart(SocketConnector.java:147)
>> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>> at org.mortbay.jetty.Server.doStart(Server.java:235)
>> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>> at org.apache.esme.JettyTestServer$.start(JettySetup.scala:64)
>> at org.apache.esme.api.ApiSpecs$.<init>(ApiTest.scala:47)
>> at org.apache.esme.api.ApiSpecs$.<clinit>(ApiTest.scala)
>> ... 19 more
>> [INFO] ------------------------------------------------------------------------
>> [ERROR] BUILD FAILURE
>> [INFO] ------------------------------------------------------------------------
>> [INFO] There are test failures.
>>
>> Please refer to
>> /Users/esjewett/svn_repos/esme/trunk/server/target/surefire-reports
>> for the individual test results.
>>
>>
>> On Fri, Nov 13, 2009 at 11:32 AM, David Pollak
>> <fe...@gmail.com> wrote:
>>> On Fri, Nov 13, 2009 at 6:50 AM, Ethan Jewett <es...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> It looks like these tests got checked in even though they don't run as
>>>> yet. Can they be commented out until they are operational? Currently
>>>> they are causing the full test run to fail, which is not the end of
>>>> the world but is something we should probably avoid.
>>>>
>>>
>>> The code I checked into the ESME SVN repo does run.
>>>
>>> If there is a problem running these tests, please let me know what the
>>> output is.
>>>
>>>
>>>>
>>>> Ethan
>>>>
>>>> On Tue, Nov 10, 2009 at 7:04 PM, David Pollak
>>>> <fe...@gmail.com> wrote:
>>>> > Folks,
>>>> >
>>>> > I started writing some ESME tests and got very cranky with Lift's TestKit
>>>> > (what kind of fool wrote those APIs anyway... oh, look, here's a mirror
>>>> and
>>>> > I'm looking at the fool).
>>>> >
>>>> > I spent a couple of hours cleaning up the Lift TestKit APIs so that tests
>>>> > will look like:
>>>> >
>>>> > "Login" in {
>>>> > for{
>>>> > login <- post("/api/login", "token" -> token) !@ "Failed to log
>>>> in"
>>>> > if (testSuccess(login))
>>>> > status <- login.get("/api/status") !@ "Failed to get status" if
>>>> > (testSuccess(status))
>>>> > } {
>>>> > (status.xml \ "user" \ "@id").text must_== theUser.id.toString
>>>> > }
>>>> > }
>>>> >
>>>> > Once the Lift changes get approved and propagated, I'll post up the new
>>>> API
>>>> > test code.
>>>> >
>>>> > I plan to spend more time in ESME-land on Thursday and will get some of
>>>> the
>>>> > user edit and OpenID stuff finished.
>>>> >
>>>> > Thanks,
>>>> >
>>>> > David
>>>> >
>>>> > PS -- What's the ETA for the new templates?
>>>> >
>>>> >
>>>> > --
>>>> > Lift, the simply functional web framework http://liftweb.net
>>>> > Beginning Scala http://www.apress.com/book/view/1430219890
>>>> > Follow me: http://twitter.com/dpp
>>>> > Surf the harmonics
>>>> >
>>>>
>>>
>>>
>>>
>>> --
>>> Lift, the simply functional web framework http://liftweb.net
>>> Beginning Scala http://www.apress.com/book/view/1430219890
>>> Follow me: http://twitter.com/dpp
>>> Surf the harmonics
>>>
>>
>
Re: Not a lot of ESME output from me today
Posted by Richard Hirsch <hi...@gmail.com>.
If you look at the console message from the last build
(http://hudson.zones.apache.org/hudson/job/ESME/lastBuild/console),
you do a see an error but a different one than Ethan mentioned. What
is strange is that I have never seen this error during my local
builds.
Even stranger is that Hudson says the test was successful.
If you look at the difference between build 4
(http://hudson.zones.apache.org/hudson/job/ESME/4/console) and 5
(http://hudson.zones.apache.org/hudson/job/ESME/5/console), you will
see that the exceptions come with the changes that occurred between 4
and 5. According to Hudson
(http://hudson.zones.apache.org/hudson/job/ESME/5/), the only changes
were David's new test cases. What is weird is that the exceptions
occur in the MsgParserSpecsAsTest where no changes occured.
The exception is below.
@Ethan: By the way, I haven't checked in your API tests, because of
the problems mentioned in my email from Nov. 9
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running org.apache.esme.AppTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.07 sec
Running org.apache.esme.lib.MsgParserSpecsAsTest
2009-11-13 12:23:37.902::INFO: Logging to STDERR via org.mortbay.log.StdErrLog
2009-11-13 12:23:37.969::INFO: jetty-6.1.21
2009-11-13 12:23:38.036::INFO: Started SocketConnector@0.0.0.0:8989
org.apache.maven.surefire.booter.SurefireExecutionException: null;
nested exception is java.lang.ExceptionInInitializerError: null
java.lang.ExceptionInInitializerError
at org.apache.esme.lib.MsgParserSpecsAsTest.<init>(MsgParseTest.scala:44)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at org.specs.runner.JUnitSuiteRunner.testSuite(JUnitSuiteRunner.scala:37)
at org.specs.runner.JUnitSuiteRunner.run(JUnitSuiteRunner.scala:45)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)
Caused by: java.lang.NullPointerException: Looking for Connection
Identifier ConnectionIdentifier(lift) but failed to find either a JNDI
data source with the name lift or a lift connection manager with the
correct name
On Fri, Nov 13, 2009 at 7:03 PM, Ethan Jewett <es...@gmail.com> wrote:
> When I do "mvn test" on my system, it bails out. The error message is
> below. It looks to me like it is not working on Hudson either, if you
> look at the test results trend on the following page:
> http://hudson.zones.apache.org/hudson/job/ESME/
>
> With regard to running tests on Hudson, I think failing tests are
> perfect, but the tests need to run through without exceptions (they
> can fail, but they can't have uncaught exceptions ... I think) or they
> will severely reduce the usability of the test suite and of the Hudson
> integration. Is that right?
>
> Thanks,
> Ethan
>
> Error from my system:
>
> 2009-11-13 13:00:38.505::WARN: failed SocketConnector@0.0.0.0:8989:
> java.net.BindException: Address already in use
> 2009-11-13 13:00:38.505::WARN: failed Server@65861e41:
> java.net.BindException: Address already in use
> org.apache.maven.surefire.booter.SurefireExecutionException: null;
> nested exception is java.lang.ExceptionInInitializerError: null
> java.lang.ExceptionInInitializerError
> at org.apache.esme.api.ApiSpecsAsTest.<init>(ApiTest.scala:43)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at org.specs.runner.JUnitSuiteRunner.testSuite(JUnitSuiteRunner.scala:37)
> at org.specs.runner.JUnitSuiteRunner.run(JUnitSuiteRunner.scala:45)
> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
> at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
> at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)
> Caused by: java.net.BindException: Address already in use
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
> at java.net.ServerSocket.bind(ServerSocket.java:319)
> at java.net.ServerSocket.<init>(ServerSocket.java:185)
> at java.net.ServerSocket.<init>(ServerSocket.java:141)
> at org.mortbay.jetty.bio.SocketConnector.newServerSocket(SocketConnector.java:80)
> at org.mortbay.jetty.bio.SocketConnector.open(SocketConnector.java:73)
> at org.mortbay.jetty.AbstractConnector.doStart(AbstractConnector.java:283)
> at org.mortbay.jetty.bio.SocketConnector.doStart(SocketConnector.java:147)
> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at org.mortbay.jetty.Server.doStart(Server.java:235)
> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at org.apache.esme.JettyTestServer$.start(JettySetup.scala:64)
> at org.apache.esme.api.ApiSpecs$.<init>(ApiTest.scala:47)
> at org.apache.esme.api.ApiSpecs$.<clinit>(ApiTest.scala)
> ... 19 more
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] There are test failures.
>
> Please refer to
> /Users/esjewett/svn_repos/esme/trunk/server/target/surefire-reports
> for the individual test results.
>
>
> On Fri, Nov 13, 2009 at 11:32 AM, David Pollak
> <fe...@gmail.com> wrote:
>> On Fri, Nov 13, 2009 at 6:50 AM, Ethan Jewett <es...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> It looks like these tests got checked in even though they don't run as
>>> yet. Can they be commented out until they are operational? Currently
>>> they are causing the full test run to fail, which is not the end of
>>> the world but is something we should probably avoid.
>>>
>>
>> The code I checked into the ESME SVN repo does run.
>>
>> If there is a problem running these tests, please let me know what the
>> output is.
>>
>>
>>>
>>> Ethan
>>>
>>> On Tue, Nov 10, 2009 at 7:04 PM, David Pollak
>>> <fe...@gmail.com> wrote:
>>> > Folks,
>>> >
>>> > I started writing some ESME tests and got very cranky with Lift's TestKit
>>> > (what kind of fool wrote those APIs anyway... oh, look, here's a mirror
>>> and
>>> > I'm looking at the fool).
>>> >
>>> > I spent a couple of hours cleaning up the Lift TestKit APIs so that tests
>>> > will look like:
>>> >
>>> > "Login" in {
>>> > for{
>>> > login <- post("/api/login", "token" -> token) !@ "Failed to log
>>> in"
>>> > if (testSuccess(login))
>>> > status <- login.get("/api/status") !@ "Failed to get status" if
>>> > (testSuccess(status))
>>> > } {
>>> > (status.xml \ "user" \ "@id").text must_== theUser.id.toString
>>> > }
>>> > }
>>> >
>>> > Once the Lift changes get approved and propagated, I'll post up the new
>>> API
>>> > test code.
>>> >
>>> > I plan to spend more time in ESME-land on Thursday and will get some of
>>> the
>>> > user edit and OpenID stuff finished.
>>> >
>>> > Thanks,
>>> >
>>> > David
>>> >
>>> > PS -- What's the ETA for the new templates?
>>> >
>>> >
>>> > --
>>> > Lift, the simply functional web framework http://liftweb.net
>>> > Beginning Scala http://www.apress.com/book/view/1430219890
>>> > Follow me: http://twitter.com/dpp
>>> > Surf the harmonics
>>> >
>>>
>>
>>
>>
>> --
>> Lift, the simply functional web framework http://liftweb.net
>> Beginning Scala http://www.apress.com/book/view/1430219890
>> Follow me: http://twitter.com/dpp
>> Surf the harmonics
>>
>
Re: Not a lot of ESME output from me today
Posted by Ethan Jewett <es...@gmail.com>.
When I do "mvn test" on my system, it bails out. The error message is
below. It looks to me like it is not working on Hudson either, if you
look at the test results trend on the following page:
http://hudson.zones.apache.org/hudson/job/ESME/
With regard to running tests on Hudson, I think failing tests are
perfect, but the tests need to run through without exceptions (they
can fail, but they can't have uncaught exceptions ... I think) or they
will severely reduce the usability of the test suite and of the Hudson
integration. Is that right?
Thanks,
Ethan
Error from my system:
2009-11-13 13:00:38.505::WARN: failed SocketConnector@0.0.0.0:8989:
java.net.BindException: Address already in use
2009-11-13 13:00:38.505::WARN: failed Server@65861e41:
java.net.BindException: Address already in use
org.apache.maven.surefire.booter.SurefireExecutionException: null;
nested exception is java.lang.ExceptionInInitializerError: null
java.lang.ExceptionInInitializerError
at org.apache.esme.api.ApiSpecsAsTest.<init>(ApiTest.scala:43)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at org.specs.runner.JUnitSuiteRunner.testSuite(JUnitSuiteRunner.scala:37)
at org.specs.runner.JUnitSuiteRunner.run(JUnitSuiteRunner.scala:45)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)
Caused by: java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
at java.net.ServerSocket.bind(ServerSocket.java:319)
at java.net.ServerSocket.<init>(ServerSocket.java:185)
at java.net.ServerSocket.<init>(ServerSocket.java:141)
at org.mortbay.jetty.bio.SocketConnector.newServerSocket(SocketConnector.java:80)
at org.mortbay.jetty.bio.SocketConnector.open(SocketConnector.java:73)
at org.mortbay.jetty.AbstractConnector.doStart(AbstractConnector.java:283)
at org.mortbay.jetty.bio.SocketConnector.doStart(SocketConnector.java:147)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.Server.doStart(Server.java:235)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.apache.esme.JettyTestServer$.start(JettySetup.scala:64)
at org.apache.esme.api.ApiSpecs$.<init>(ApiTest.scala:47)
at org.apache.esme.api.ApiSpecs$.<clinit>(ApiTest.scala)
... 19 more
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] There are test failures.
Please refer to
/Users/esjewett/svn_repos/esme/trunk/server/target/surefire-reports
for the individual test results.
On Fri, Nov 13, 2009 at 11:32 AM, David Pollak
<fe...@gmail.com> wrote:
> On Fri, Nov 13, 2009 at 6:50 AM, Ethan Jewett <es...@gmail.com> wrote:
>
>> Hi,
>>
>> It looks like these tests got checked in even though they don't run as
>> yet. Can they be commented out until they are operational? Currently
>> they are causing the full test run to fail, which is not the end of
>> the world but is something we should probably avoid.
>>
>
> The code I checked into the ESME SVN repo does run.
>
> If there is a problem running these tests, please let me know what the
> output is.
>
>
>>
>> Ethan
>>
>> On Tue, Nov 10, 2009 at 7:04 PM, David Pollak
>> <fe...@gmail.com> wrote:
>> > Folks,
>> >
>> > I started writing some ESME tests and got very cranky with Lift's TestKit
>> > (what kind of fool wrote those APIs anyway... oh, look, here's a mirror
>> and
>> > I'm looking at the fool).
>> >
>> > I spent a couple of hours cleaning up the Lift TestKit APIs so that tests
>> > will look like:
>> >
>> > "Login" in {
>> > for{
>> > login <- post("/api/login", "token" -> token) !@ "Failed to log
>> in"
>> > if (testSuccess(login))
>> > status <- login.get("/api/status") !@ "Failed to get status" if
>> > (testSuccess(status))
>> > } {
>> > (status.xml \ "user" \ "@id").text must_== theUser.id.toString
>> > }
>> > }
>> >
>> > Once the Lift changes get approved and propagated, I'll post up the new
>> API
>> > test code.
>> >
>> > I plan to spend more time in ESME-land on Thursday and will get some of
>> the
>> > user edit and OpenID stuff finished.
>> >
>> > Thanks,
>> >
>> > David
>> >
>> > PS -- What's the ETA for the new templates?
>> >
>> >
>> > --
>> > Lift, the simply functional web framework http://liftweb.net
>> > Beginning Scala http://www.apress.com/book/view/1430219890
>> > Follow me: http://twitter.com/dpp
>> > Surf the harmonics
>> >
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
Re: Not a lot of ESME output from me today
Posted by David Pollak <fe...@gmail.com>.
On Fri, Nov 13, 2009 at 6:50 AM, Ethan Jewett <es...@gmail.com> wrote:
> Hi,
>
> It looks like these tests got checked in even though they don't run as
> yet. Can they be commented out until they are operational? Currently
> they are causing the full test run to fail, which is not the end of
> the world but is something we should probably avoid.
>
The code I checked into the ESME SVN repo does run.
If there is a problem running these tests, please let me know what the
output is.
>
> Ethan
>
> On Tue, Nov 10, 2009 at 7:04 PM, David Pollak
> <fe...@gmail.com> wrote:
> > Folks,
> >
> > I started writing some ESME tests and got very cranky with Lift's TestKit
> > (what kind of fool wrote those APIs anyway... oh, look, here's a mirror
> and
> > I'm looking at the fool).
> >
> > I spent a couple of hours cleaning up the Lift TestKit APIs so that tests
> > will look like:
> >
> > "Login" in {
> > for{
> > login <- post("/api/login", "token" -> token) !@ "Failed to log
> in"
> > if (testSuccess(login))
> > status <- login.get("/api/status") !@ "Failed to get status" if
> > (testSuccess(status))
> > } {
> > (status.xml \ "user" \ "@id").text must_== theUser.id.toString
> > }
> > }
> >
> > Once the Lift changes get approved and propagated, I'll post up the new
> API
> > test code.
> >
> > I plan to spend more time in ESME-land on Thursday and will get some of
> the
> > user edit and OpenID stuff finished.
> >
> > Thanks,
> >
> > David
> >
> > PS -- What's the ETA for the new templates?
> >
> >
> > --
> > Lift, the simply functional web framework http://liftweb.net
> > Beginning Scala http://www.apress.com/book/view/1430219890
> > Follow me: http://twitter.com/dpp
> > Surf the harmonics
> >
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
Re: Not a lot of ESME output from me today
Posted by Ethan Jewett <es...@gmail.com>.
Hi,
It looks like these tests got checked in even though they don't run as
yet. Can they be commented out until they are operational? Currently
they are causing the full test run to fail, which is not the end of
the world but is something we should probably avoid.
Ethan
On Tue, Nov 10, 2009 at 7:04 PM, David Pollak
<fe...@gmail.com> wrote:
> Folks,
>
> I started writing some ESME tests and got very cranky with Lift's TestKit
> (what kind of fool wrote those APIs anyway... oh, look, here's a mirror and
> I'm looking at the fool).
>
> I spent a couple of hours cleaning up the Lift TestKit APIs so that tests
> will look like:
>
> "Login" in {
> for{
> login <- post("/api/login", "token" -> token) !@ "Failed to log in"
> if (testSuccess(login))
> status <- login.get("/api/status") !@ "Failed to get status" if
> (testSuccess(status))
> } {
> (status.xml \ "user" \ "@id").text must_== theUser.id.toString
> }
> }
>
> Once the Lift changes get approved and propagated, I'll post up the new API
> test code.
>
> I plan to spend more time in ESME-land on Thursday and will get some of the
> user edit and OpenID stuff finished.
>
> Thanks,
>
> David
>
> PS -- What's the ETA for the new templates?
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
Re: Not a lot of ESME output from me today
Posted by David Pollak <fe...@gmail.com>.
On Wed, Nov 11, 2009 at 1:40 AM, Anne Kathrine Petterøe <
akpetteroe@gmail.com> wrote:
> PS -- What's the ETA for the new templates?
>>
>
> Joy (the designer) has converted all pages and is currently testing in IE6.
> We should have the templates by the end of this week.
>
Woo Hoo!
>
> /Anne
>
>
> On 11. nov. 2009, at 01.04, David Pollak wrote:
>
> Folks,
>>
>> I started writing some ESME tests and got very cranky with Lift's TestKit
>> (what kind of fool wrote those APIs anyway... oh, look, here's a mirror
>> and
>> I'm looking at the fool).
>>
>> I spent a couple of hours cleaning up the Lift TestKit APIs so that tests
>> will look like:
>>
>> "Login" in {
>> for{
>> login <- post("/api/login", "token" -> token) !@ "Failed to log in"
>> if (testSuccess(login))
>> status <- login.get("/api/status") !@ "Failed to get status" if
>> (testSuccess(status))
>> } {
>> (status.xml \ "user" \ "@id").text must_== theUser.id.toString
>> }
>> }
>>
>> Once the Lift changes get approved and propagated, I'll post up the new
>> API
>> test code.
>>
>> I plan to spend more time in ESME-land on Thursday and will get some of
>> the
>> user edit and OpenID stuff finished.
>>
>> Thanks,
>>
>> David
>>
>> PS -- What's the ETA for the new templates?
>>
>>
>> --
>> Lift, the simply functional web framework http://liftweb.net
>> Beginning Scala http://www.apress.com/book/view/1430219890
>> Follow me: http://twitter.com/dpp
>> Surf the harmonics
>>
>
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
Re: Not a lot of ESME output from me today
Posted by Anne Kathrine Petterøe <ak...@gmail.com>.
> PS -- What's the ETA for the new templates?
Joy (the designer) has converted all pages and is currently testing in
IE6.
We should have the templates by the end of this week.
/Anne
On 11. nov. 2009, at 01.04, David Pollak wrote:
> Folks,
>
> I started writing some ESME tests and got very cranky with Lift's
> TestKit
> (what kind of fool wrote those APIs anyway... oh, look, here's a
> mirror and
> I'm looking at the fool).
>
> I spent a couple of hours cleaning up the Lift TestKit APIs so that
> tests
> will look like:
>
> "Login" in {
> for{
> login <- post("/api/login", "token" -> token) !@ "Failed to
> log in"
> if (testSuccess(login))
> status <- login.get("/api/status") !@ "Failed to get status" if
> (testSuccess(status))
> } {
> (status.xml \ "user" \ "@id").text must_== theUser.id.toString
> }
> }
>
> Once the Lift changes get approved and propagated, I'll post up the
> new API
> test code.
>
> I plan to spend more time in ESME-land on Thursday and will get some
> of the
> user edit and OpenID stuff finished.
>
> Thanks,
>
> David
>
> PS -- What's the ETA for the new templates?
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics