Comments (23)
Repo created at https://github.com/hamcrest/hamcrest-junit
from javahamcrest.
I've copied the JUnit code that depends on Hamcrest and Hamcrest library code that depends on JUnit here: https://github.com/hamcrest/hamcrest-junit and repackaged into org.hamcrest.junit.
I've made the tests pass and set up a Travis CI build here: https://travis-ci.org/hamcrest/hamcrest-junit
I've ensured that the hamcrest-junit code does not pass Hamcrest types to JUnit, so that JUnit can break its dependency on Hamcrest some time in the future.
from javahamcrest.
Still to do - publish to Maven central
from javahamcrest.
I'm not sure if this is in scope, but I figured it's worth writing down somewhere.
Currently, MatcherAssert.assertThat
throws a java.lang.AssertionError
on failure with the description built by the matcher. This description can sometimes get pretty massive. By contrast, Assert.assertEquals
throws an org.junit.ComparisonFailure
, which is a subclass of AssertionError
that conveys more information that allows an IDE or something like it to display a diff of the expected and actual results.
Using this sort of thing would be incredibly useful in Hamcrest. However, it's in the JUnit JAR and package structure, not Hamcrest's. Would it be worth creating something like it in hamcrest-junit so that the behaviour (specifically, diffs in the IDE) can be shared between both projects?
from javahamcrest.
That's a good idea but I'm not sure how to do it. AssertThat doesn't see
the expected value, only Matchers that define expected aspects of the
actual value.
It's definitely out of scope for the first release but if you submit a PR
to the hamcrest-junit project we can include it in a later release.
On Wednesday, December 31, 2014, Samir Talwar [email protected]
wrote:
I'm not sure if this is in scope, but I figured it's worth writing down
somewhere.Currently, MatcherAssert.assertThat throws a java.lang.AssertionError on
failure with the description built by the matcher. This description can
sometimes get pretty massive. By contrast, Assert.assertEquals throws an
org.junit.ComparisonFailure, which is a subclass of AssertionError that
conveys more information that allows an IDE or something like it to display
a diff of the expected and actual results.Using this sort of thing would be incredibly useful in Hamcrest. However,
it's in the JUnit JAR and package structure, not Hamcrest's. Would it be
worth creating something like it in hamcrest-junit so that the behaviour
(specifically, diffs in the IDE) can be shared between both projects?—
Reply to this email directly or view it on GitHub
#92 (comment)
.
from javahamcrest.
Sounds reasonable. Will do soon-ish.
from javahamcrest.
Are you expecting that the code in org.junit.internal
will be rewritten to avoid Hamcrest or that the appropriate functionality will be moved to supporting methods and classes in hamcrest-junit
?
from javahamcrest.
Junit should be free of hamcrest at some point. Some of that will be achieved by moving stuff into hamcrest-junit
S
Sent from a device without a keyboard. Please excuse brevity, errors, and embarrassing autocorrections.
On 31 Dec 2014, at 12:04, Samir Talwar [email protected] wrote:
Are you expecting that the code in org.junit.internal will be rewritten to avoid Hamcrest or that the appropriate functionality will be moved to supporting methods and classes in hamcrest-junit?
—
Reply to this email directly or view it on GitHub.
from javahamcrest.
@SamirTalwar - Code in org.junit.internal will have to be rewritten to remove references to Hamcrest. We're not doing anything about internal JUnit implementation details.
from javahamcrest.
hamcrest-junit 1.0.0.0-RC1 is now in Maven central. https://repo1.maven.org/maven2/org/hamcrest/hamcrest-junit/1.0.0.0-RC1/
from javahamcrest.
@npryce Thanks for taking a first step into this direction. I'm one of the maintainers of JUnit. We have had some discussion about modularizing JUnit. junit-hamcrest would have been a potential outcome of this.
@stefanbirkner posted a link to your blog post on the JUnit mailing list. One users replied with a number of concerns: https://groups.yahoo.com/neo/groups/junit/conversations/messages/24626. I share some of those concerns.
@npryce Do you have time to take a look?
from javahamcrest.
I'll join the JUnit group and give my thoughts
On Saturday, January 10, 2015, Marc Philipp [email protected]
wrote:
@npryce https://github.com/npryce Thanks for taking a first step into
this direction. I'm one of the maintainers of JUnit. We have had some
thoughts about modularizing JUnit. junit-hamcrest would have been a
potential outcome of this.@stefanbirkner https://github.com/stefanbirkner posted a link to your
blog post on the JUnit mailing list. One users replied with a number of
concerns:
https://groups.yahoo.com/neo/groups/junit/conversations/messages/24626. I
share some of those concerns.@npryce https://github.com/npryce Do you have time to take a look?
—
Reply to this email directly or view it on GitHub
#92 (comment)
.
from javahamcrest.
@marcphilipp - I posted to the JUnit list but got no response. Did you see the message?
from javahamcrest.
@npryce Yes, I did see it. I haven't had time to respond yet, but will do so. I think you have silenced the most pressing concerns.
BTW What's the plan for Hamcrest 2.0? Is there a publicly available "roadmap"?
from javahamcrest.
Great. And (of course) I'd be happy for JUnit maintainers to collaborate on hamcrest-junit.
from javahamcrest.
We're in the midst of a discussion regarding our plans for JUnit 5. We will definitely get back to you. It might take some time, though.
If you need feedback from us, please don't hesitate to ping us over at junit-team/junit or through the mailing list.
from javahamcrest.
Hi. I am another of the maintainers of JUnit.
Any chance that java-hamcrest can depend on JDK 6, not JDK 7? JUnit is used in a number of environments (GWT, Android, possibly Java ME). Some of our users have large systems, and cannot quickly update their JDK.
The JUnit teams' current plan was to have JUnit 5 require JDK 6. (JUnit 4.x only requires JDK 5). If we are to start to remove the dependency from Hamcrest, we might end up migrating the tests of JUnit itself use hamcrest-junit. It would be great to start that process soon, but we rather not have JUnit 5 require JDK 7.
from javahamcrest.
I've opened #105 regarding the JDK 7 requirement.
from javahamcrest.
Proposal: In addition to what has been released so far, we/you release hamcrest-junit 1.3 which depends on hamcrest-core 1.3. Both artifacts are compiled with target JDK 1.6.
That would not only allow JUnit to keep it's test dependency on hamcrest but in addition would make it possible to use JUnit 5 (which will not depend on Hamcrest anymore) along with hamcrest-junit 1.3 on JDK 6.
Does that make sense?
from javahamcrest.
There is already a hamcrest-junit 1.0.0.0 release that depends on hamcrest 1.3. If that is not compatible with JDK 1.6, I can publish a new release (1.0.0.1) that is.
from javahamcrest.
I've created a 1.x.x.x branch of hamcrest-junit and Travis is building that with Java 1.6. https://travis-ci.org/hamcrest/hamcrest-junit/builds/64050527
I'll publish a 1.0.0.1 release from that branch built with 1.6
from javahamcrest.
Before you release it we should fix hamcrest/hamcrest-junit#5 first, right?
from javahamcrest.
I've released Hamcrest-JUnit 1.0.0.1, which is compiled with JDK 1.6.
I didn't notice your comment. We can publish other releases (1.0.1.0, 2.0.1.0) with the generic error collector.
from javahamcrest.
Related Issues (20)
- Conflicting license declarations HOT 1
- Not sure why assertThat() doesn't work in this case HOT 2
- 301 Moved Permanently
- assertThat(this.object, hasProperty("booleanName")) fails to match boolean types and renames the property HOT 1
- The matcher contains() is misleading HOT 2
- FR: Matching maps with various type HOT 1
- oss-fuzz integration
- Participitation in Hacktoberfest?
- HasProperty Matcher doesn't work with Java Records HOT 1
- assertThat(Int::class.java, typeCompatibleWith(Number::class.java)) in kotlin always fails
- hamcrest matching on actual empty list fails with nosuchmethoderror HOT 1
- Test output Alignment
- record version fails the hasProperty HOT 1
- has property fails with non public class.. not sure if this correct as per java standards of property
- Double "close-to" matcher that uses the ULP.
- GraalVM Native Image support HOT 3
- Inquiry about Project Activity and Future Plans HOT 13
- Compatibility in java versions HOT 2
- Upgrade build to JDK 1.8 bytecode HOT 1
- Upgrade to latest Gradle HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from javahamcrest.