TST: Fix assertNotIsInstance msg

[sinhrks]

• tests added / passed
• passes git diff upstream/master | flake8 --diff

The current error message below is confusing.

tm.assertNotIsInstance(pd.Series([1]), pd.Series)
# AssertionError: Expected object to be of type <class 'pandas.core.series.Series'>, found <class 'pandas.core.series.Series'> instead

[jreback]

so lots of things fail on windows. probably all because of comparisons on int32/int64.

e.g. np.array([1,2,3]) constructs as int32 on windows. So if you are comparing to something just force the constrution with np.array([1,2,3],dtype=np.int64). If you ARE expecting platform int, then use dtype=np.intp

btw you can setup appveyor (just need to login it free), to at least see build failures. its slow but can give you a feel for errors.

======================================================================
FAIL: pandas.tests.test_tseries.test_outer_join_indexer
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Miniconda2\envs\pandas3.5\lib\site-packages\nose\case.py", line 198, in runTest
    self.test(*self.arg)
  File "C:\Users\conda\Documents\pandas3.5\pandas\tests\test_tseries.py", line 133, in test_outer_join_indexer
    assert_almost_equal(bres, bexp)
  File "C:\Users\conda\Documents\pandas3.5\pandas\util\testing.py", line 131, in assert_almost_equal
    return _testing.assert_almost_equal(left, right, **kwargs)
  File "pandas\src\testing.pyx", line 58, in pandas._testing.assert_almost_equal (pandas\src\testing.c:3479)
    cpdef assert_almost_equal(a, b, bint check_less_precise=False, check_dtype=True,
  File "pandas\src\testing.pyx", line 131, in pandas._testing.assert_almost_equal (pandas\src\testing.c:2184)
    assert_attr_equal('dtype', a, b, obj=obj)
  File "C:\Users\conda\Documents\pandas3.5\pandas\util\testing.py", line 820, in assert_attr_equal
    left_attr, right_attr)
  File "C:\Users\conda\Documents\pandas3.5\pandas\util\testing.py", line 931, in raise_assert_detail
    raise AssertionError(msg)
AssertionError: numpy array are different

Attribute "dtype" are different
[left]:  int64
[right]: int32

----------------------------------------------------------------------
Ran 10142 tests in 405.745s

FAILED (SKIP=182, failures=52)

-> assert_almost_equal(ares, aexp)
(Pdb) l
104         index_exp = np.array([3, 5], dtype=np.int64)
105         assert_almost_equal(index, index_exp)
106
107         aexp = np.array([2, 4])
108         bexp = np.array([1, 2])
109  ->     assert_almost_equal(ares, aexp)
110         assert_almost_equal(bres, bexp)
111
112         a = np.array([5], dtype=np.int64)
113         b = np.array([5], dtype=np.int64)
114
(Pdb) p ares
array([2, 4], dtype=int64)
(Pdb) p bexp
array([1, 2])
(Pdb) p bexp.dtype
dtype('int32')
(Pdb) l 100
 95         assert (np.array_equal(ridx, exp_ridx))
 96
 97
 98     def test_inner_join_indexer():
 99         a = np.array([1, 2, 3, 4, 5], dtype=np.int64)
100         b = np.array([0, 3, 5, 7, 9], dtype=np.int64)
101
102         index, ares, bres = algos.inner_join_indexer_int64(a, b)
103
104         index_exp = np.array([3, 5], dtype=np.int64)
105         assert_almost_equal(index, index_exp)
(Pdb) l
106
107         aexp = np.array([2, 4])
108         bexp = np.array([1, 2])
109  ->     assert_almost_equal(ares, aexp)
110         assert_almost_equal(bres, bexp)
111
112         a = np.array([5], dtype=np.int64)
113         b = np.array([5], dtype=np.int64)
114
115         index, ares, bres = algos.inner_join_indexer_int64(a, b)
116         assert_almost_equal(index, [5])
(Pdb) p bexp
array([1, 2])
(Pdb) p ares
array([2, 4], dtype=int64)
(Pdb)

[max-sixty]

Why do we need our own here? Nosetests has a pretty reasonable one:

    def assertIsInstance(self, obj, cls, msg=None):
        """Same as self.assertTrue(isinstance(obj, cls)), with a nicer
        default message."""
        if not isinstance(obj, cls):
            standardMsg = '%s is not an instance of %r' % (safe_repr(obj), cls)
            self.fail(self._formatMessage(msg, standardMsg))

(...although not as reasonable as pytest...)

[jreback]

we define everything already so you can either do: self.assertIsInstance or tm.assertIsInstance.

[max-sixty]

Right, makes sense.

General marketing of pytest: in pytest you can just do assert isinstance(x, x), and it writes the error message, which is all nice and pythonic

[jreback]

@MaximilianR of course everyone likes pytest better. I have used it for years. But changing would be a bear, not sure if its worth it.

[max-sixty]

Yeah.
How dependent is the testing suite on nosetests, vs just unittest?

We were using nosetests, moved to pytest, and it worked really seamlessly. But that's because we were really only using nosetests as the runner, rather than any nose-specific features

[jreback]

I think it would work right away. But, the power if pytest is really using fixtures, parameterized tests, and clean looking asserts.

So need to convert most setUp/tearDown stuff to fixtures (a lot). properly use fixture scope (e.g. db stuff which you only want to create a database once per test run; this is the most complicated).

Parameterized tests are awesome, but again, need to restructure tests a bit for that.

I suppose the actual assert mechanism could be changed, but a lot of care would be needed.

And here's the rub, I think we would have to simply switch, then start changing things as its not back-compat to nose.

Given all this I am not optomistic this could be done quickly/easily. The upside is nice & clean tests, but getting there is hard.

[max-sixty]

I think it would work right away. But, the power if pytest is really using fixtures, parameterized tests, and clean looking asserts.
And here's the rub, I think we would have to simply switch, then start changing things as its not back-compat to nose.

So what's in the way of making the change to py.test and then in time move over to using its features? There's no need to move everything over immediately?

[jreback]

nothing really. If you want to investigate actually seeing what would be needed to be changed to simply run it (and might involved a py.test compat plugin), then would be willing to switch I think. Though of course would be nice to see what is involved in adding these things: fixtures, assertion nomenclature, parameterization (e.g. maybe do one test file to see what its like).

This was discussed a little bit on the mailing list, but I don't think an issue exists for it.

[sinhrks]

@jreback above comment is for #13088, and will check there.

[jreback]

@sinhrks right sorry!