Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Time to kill data-laden falsehood? #175

Closed
marick opened this issue Feb 14, 2013 · 3 comments
Closed

Time to kill data-laden falsehood? #175

marick opened this issue Feb 14, 2013 · 3 comments
Labels

Comments

@marick
Copy link
Owner

marick commented Feb 14, 2013

Midje adds a new kind of falsehood to Clojure: "data-laden". It's a typed map that contains the extra note output that the collection and chatty checkers put out. The problem is that Clojure predicates will treat data-laden falsehoods as truthy. That requires some care in the Midje code, but there's not much chance that it will affect user code. But there is some chance. Consider this:

user=> (fact [[1] [2]] => (partial every? (just [1])))
true

The problem is that just produces a data-laden falsehood, which every? turns into true.

This can be avoided by using the has checker:

user=> (fact [[1] [2]] => (has every? (just [1])))

FAIL at (NO_SOURCE_PATH:1)
Actual result did not agree with the checking function.
        Actual result: [[1] [2]]
    Checking function: (has every? (just [1]))
false

The reason has works is that it "lifts" the quantifier so that it recognizes data-laden falsehoods.

That's all fine so long as people remember to use has. I don't like depending on that, especially when not remembering makes a fact pass when it shouldn't.

With the new reporting framework, it occurs to me we could have chatty and collection checkers emit notes when they discover a problem. At the end of a check, the emission framework would print the usual failure message plus any notes.

This introduces ugly state into the equation, but it's really just state that already exists. And there are already side-effecting emission functions scattered around the code.

@josephwilk
Copy link
Contributor

Yes, feels like data-laden falsehood would only be viable if it is completely abstracted from the user.

The fact that it bleeds through in a potential false positive is scary!

Emitting notes sounds interesting. I like that it seperates the concern of reporting and failure. I would hope that it makes some of the code around the complex failure representation simpler.

@marick
Copy link
Owner Author

marick commented Feb 15, 2013

Yes, I think this should be fixed. I want to get 1.5 finished first, though.

@marick
Copy link
Owner Author

marick commented Nov 22, 2015

This will happen in 2.0, and I don't want it cluttering up the issues list.

@marick marick closed this as completed Nov 22, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants