Good idea, thanks for pointing this out Stuart. I had originally been
considering doing something like this but forgot all about it when I
came up with the current implementation. This will be much simpler
than the :use wrangling I have now.
- Matt
On Jun 12, 8:26 am, Stuart Halloway wrote:
>
Hi Matt,
I think it is important to have a one-line solution for using the
library with test-is. If you are going this route, I would have the
adapter namespace immigrate in all (except expect) from the test-
expect namespace. That way a single (use 'clojure.contrib.test-
expect.test-is) wo
The agreement is signed and in the (snail) mail.
Also, I think I found a solution to the original problem that spurred
this thread. In the test-is-adapter namespace I have added an expect
macro that wraps the standard expect macro with a binding for the test-
is specific report-problem function.
Matt is signing the CA and I will be adding test-expect to contrib.
Stu
>
> Can I help from the test-is side? Could test-expect be added to
> clojure-contrib?
> -Stuart
>
>
> On Jun 10, 1:36 pm, Matt Clark wrote:
>> Thanks for these ideas, I will give them a try tonight and update the
>> adapt
Can I help from the test-is side? Could test-expect be added to
clojure-contrib?
-Stuart
On Jun 10, 1:36 pm, Matt Clark wrote:
> Thanks for these ideas, I will give them a try tonight and update the
> adapter namespace with the changes. If anyone knows of a more
> idiomatic way I could have i
Thanks for these ideas, I will give them a try tonight and update the
adapter namespace with the changes. If anyone knows of a more
idiomatic way I could have implemented the problem reporting
functionality that would prevent the necessity of these "hacky"
solutions, I'm all ears.
- Matt
On Jun
On Jun 10, 10:39 am, Stuart Halloway
wrote:
> (defn use-test-is! []
> (require 'mdc.common.test-expect.test-is-adapter)
> (def report-problem (ns-resolve 'mdc.common.test-expect.test-is-
> adapter 'report-problem)))
>
> This feels a little hacky, but is there a better way?
It's not much less
Matt Clark's test-expect library includes two versions of a report-
problem function: a standalone version, and another that integrates
with test-is. The comments suggest two ways to active the test-is
version: wrapping calls to expect in a binding, and interning the
specialized version of