testtools-dev team mailing list archive

[Jonathan Lange <jonathan.lange@xxxxxxxxx>]

I forgot to mention also that there's work ongoing to expose "expectThat",
which has the same API but raising non-fatally. I don't have the details
paged in, but whatever goes on with assert_that should be aware of
expectThat.

On Tue Dec 03 2013 at 2:55:58 PM, Jonathan Lange <jonathan.lange@xxxxxxxxx>
wrote:

> I think it's a good idea, see
> https://bugs.launchpad.net/testtools/+bug/1243834
>
> Notionally, TestCase.failException is a public, writeable attribute that
> can change. Tests must raise self.failException if they want to fail rather
> than error.
>
> In practice, it's rarely set, so raising MismatchError (which is a
> subclass of AssertionError, which is the default failException) should be
> fine. It might be nice to have an even lower level function that does not
> assume MismatchError.
>
> Parametrizing the tests would be nice.
>
>
>
> On Sat Nov 30 2013 at 11:37:59 AM, Daniel Watkins <
> daniel@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> Hello all,
>
> I've just opened https://github.com/testing-cabal/testtools/pull/70
> which introduces an assert_that function.
>
> This will allow matchers to be used outside of the TestCase context.
> This is useful for people who can't buy in to testtools.TestCase fully
> (for whatever reason), or who like using function/generator tests (as
> supported by nose).
>
> This isn't a full patch (and so shouldn't be merged as-is), but I wanted
> to get feedback on whether this approach would be acceptable before
> doing anything else.
>
> Assuming it is acceptable, thoughts on how best to test it would be
> appreciated. My initial instinct was to modify all of the tests
> exercising the core behaviour I've extracted to point at assert_that and
> write some new tests to ensure that assertThat consumes the assert_that
> API correctly.
>
> However, as we will be exposing essentially the same API in two places
> (assert_that and self.assertThat), I wonder if we should run the
> core-behaviour tests against both places by parameterising them somehow,
> so we're fully testing our public API. Thoughts appreciated.
>
>
> Please do let me know what you think!
>
>
> Thanks,
>
> Dan
>
> _______________________________________________
> Mailing list: https://launchpad.net/~testtools-dev
> Post to     : testtools-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~testtools-dev
> More help   : https://help.launchpad.net/ListHelp
>
>