That sound very exciting! I just cloned the repository and tried to run the tests, however, none of them succeeds. Maybe I’m missing still a part on my side.
What I’ve done (environment OS X 10.9.2):
a) command line
- clone of your repository
- started mvn test with path to war file
b) IntelliJ JUnit
- Run of BuildHistoryTest
c) IntelliJ
- Run of freestyle_build.feature
I always get an exception:
----------------------------------------------------------------------------------------------------------------------------------------
com.google.inject.ProvisionException: Guice provision errors:
1) Error injecting constructor, java.lang.Error: Failed to wait for condition
org.jenkinsci.test.acceptance.po.CapybaraPortingLayer$1@51bea01c
at org.jenkinsci.test.acceptance.po.Jenkins.<init>(Jenkins.java:35)
at org.jenkinsci.test.acceptance.po.Jenkins.class(Jenkins.java:29)
while locating org.jenkinsci.test.acceptance.po.Jenkins
for field at core.BuildHistoryTest.j(BuildHistoryTest.java:19)
while locating core.BuildHistoryTest
1 error
at
com.google.inject.internal.Errors.throwProvisionExceptionIfErrorsExist(Errors.java:451)
at
com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:65)
at
com.google.inject.internal.InjectorImpl.injectMembers(InjectorImpl.java:944)
at
org.jenkinsci.test.acceptance.junit.JenkinsAcceptanceTestRule$1.evaluate(JenkinsAcceptanceTestRule.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:74)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:202)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:65)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.lang.Error: Failed to wait for condition
org.jenkinsci.test.acceptance.po.CapybaraPortingLayer$1@51bea01c
at
org.jenkinsci.test.acceptance.po.CapybaraPortingLayer.waitForCond(CapybaraPortingLayer.java:97)
at
org.jenkinsci.test.acceptance.po.CapybaraPortingLayer.waitForCond(CapybaraPortingLayer.java:107)
at
org.jenkinsci.test.acceptance.po.CapybaraPortingLayer.waitFor(CapybaraPortingLayer.java:70)
at org.jenkinsci.test.acceptance.po.Jenkins.getVersion(Jenkins.java:45)
at org.jenkinsci.test.acceptance.po.Jenkins.<init>(Jenkins.java:30)
at org.jenkinsci.test.acceptance.po.Jenkins.<init>(Jenkins.java:35)
at
org.jenkinsci.test.acceptance.po.Jenkins$$FastClassByGuice$$9bbc559e.newInstance(<generated>)
at
com.google.inject.internal.cglib.reflect.$FastConstructor.newInstance(FastConstructor.java:40)
at
com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:60)
at
com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:85)
at
com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:254)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at org.jenkinsci.test.acceptance.guice.World$1$1.get(World.java:74)
at
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)
at
com.google.inject.internal.SingleFieldInjector.inject(SingleFieldInjector.java:53)
at
com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:110)
at
com.google.inject.internal.MembersInjectorImpl$1.call(MembersInjectorImpl.java:75)
at
com.google.inject.internal.MembersInjectorImpl$1.call(MembersInjectorImpl.java:73)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1024)
at
com.google.inject.internal.MembersInjectorImpl.injectAndNotify(MembersInjectorImpl.java:73)
at
com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:60)
... 20 more
Caused by: org.openqa.selenium.TimeoutException: Failed to wait for condition
org.jenkinsci.test.acceptance.po.CapybaraPortingLayer$1@51bea01c
Build info: version: '2.40.0', revision:
'4c5c0568b004f67810ee41c459549aa4b09c651e', time: '2014-02-19 11:13:01'
System info: host: 'duckjibe', ip: '10.0.0.107', os.name: 'Mac OS X', os.arch:
'x86_64', os.version: '10.9.2', java.version: '1.7.0_45'
Driver info: driver.version: unknown
at
org.jenkinsci.test.acceptance.po.CapybaraPortingLayer.waitForCond(CapybaraPortingLayer.java:95)
... 42 more
----------------------------------------------------------------------------------------------------------------------------------------
Am 03.03.2014 um 06:42 schrieb Kohsuke Kawaguchi <[email protected]>:
> Vivek and I have ported all the lower layers of the test harness. This
> includes JenkinsController, Docker support, Guice-based object world,
> Cucumber integration, and JUnit integration.
>
> I can run tests from IDEs individually for both Cucumber and JUnit, although
> I just realized that I haven't added glue to make all cucumber tests run from
> "mvn test". JUnit portion obviously does run with "mvn test".
>
> We kept the configuration mechanism backward compatible, but I also added a
> configuration mechanism based on Guice-binding [1].
>
> I've added a set of classes to mimic Capybara methods that we use regularly
> on top of WebDriver. This made the porting process fairly straight-forward.
>
> Page objects and step definitions were ported by using test cases as the
> driver (I rely on IntelliJ's auto-fix functionality to generate steps one at
> a time.) So far I have only fully ported freestyle_project.feature, then
> ant_plugin.feature to JUnit test format. There are still many more steps and
> page objects to complete, although at this point I feel the rest of the
> process is fairly mechanical --- so any help in porting feature files would
> be appreciated. Just claim your feature file, and push your changes.
>
> So far, I'm hearing people favoring JUnit tests, including Oliver who is the
> most active in this project. So I'm starting to think that maybe I'd port
> other cucumber tests into JUnit format. I continue to welcome feedbacks from
> others in this area.
>
> I need to document a lot of things, and I still intend to, but I have to hack
> this coming week on something else. I plan on coming back to this in the next
> weekend. In the mean time, hopefully the code is not too large and simple
> enough for you everyone to see.
>
>
> [1]
> http://kohsuke.org/2014/03/01/potd-application-configuration-via-guice-binding-groovy/
>
>
> 2014-02-28 12:14 GMT-08:00 Kohsuke Kawaguchi <[email protected]>:
> Stephen made a point to me in a dev meet-up at FOSDEM that he likes Cucumber
> in that tests are more readable (even to developers), even though he was
> sympathetic to the overhead for authors of tests.
>
> So I think I am going to leave them alone. Cucumber has another nice
> characteristic that tests that depend on not-yet-ported steps will be marked
> as pending, so I can see how far off I am from getting back to the parity.
>
> And yes, you will get the ability to write tests in plain-old JUnit4 tests
> (which I consider the porting from writing tests in rspec.) Personally, I'd
> be writing tests in plain-old JUnit4 tests on Groovy.
>
> I'm curious to hear from other users on their take on BDD/Cucumber vs JUnit.
>
>
>
> 2014-02-28 11:06 GMT-08:00 oliver gondža <[email protected]>:
>
> Mostly same story here with the exception I have never felt comfortable or
> productive working in ruby.
>
> Btw, you have expressed dislike towards Cucumber/BDD style features in the
> past. Can we take this opportunity to get rid of it as well? It should not
> mean significantly more work and if it can bring new people in, I think it
> might be worth to try.
>
> --
> oliver
>
>
>
> --
> Kohsuke Kawaguchi
>
>
>
> --
> Kohsuke Kawaguchi
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
signature.asc
Description: Message signed with OpenPGP using GPGMail
