Convert use of assert_/assert to specialized asserts in tests

[ghost]

An example of an exception that uses assert_:

============================================================================
FAILURE: test_class_ops (pandas.tseries.tests.test_timeseries.TestTimestamp)
----------------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\Python33-AMD64\Lib\unittest\case.py", line 384, in _executeTestPart
    function()
  File "C:\workspace\pandas_tests\BITS\64\PYTHONVER\33\pandas\tseries\tests\test_timeseries.py", line 2513, in test_class_ops
    compare(Timestamp.now('UTC'),datetime.now(pytz.timezone('UTC')))
  File "C:\workspace\pandas_tests\BITS\64\PYTHONVER\33\pandas\tseries\tests\test_timeseries.py", line 2510, in compare
    self.assert_(int(Timestamp(x).value/1e9) == int(Timestamp(y).value/1e9))
  File "c:\Python33-AMD64\Lib\unittest\case.py", line 1140, in deprecated_func
    return original_func(*args, **kwargs)
  File "c:\Python33-AMD64\Lib\unittest\case.py", line 520, in assertTrue
    raise self.failureException(msg)
AssertionError: False is not true

note the line:

self.assert_(int(Timestamp(x).value/1e9) == int(Timestamp(y).value/1e9))

if this had been assertEqual, we'd have seen what the value were
and been able to debug easier (now fixed). (though, It should be obvious why that test is unreliable).

There are lots of these across the tests.
If someone steps up to do this, do a little bit at a time.
a PR that touches 200 tests will defy review and be stuck forever
in PR limbo.

[jreback]

anyway just to fix assert_ itself?
I use that almost exclusively

[ghost]

Using self.assert_(x == y) doesn't tell you what x and y were when failing,
assertEqual does, so at least in that case you should use assertEqual.

[jreback]

and you learn something new every day...ok!

[ghost]

On a good day, I do.

[ghost]

Similar problem from test_parsing_timezone_offsets and co'

        self.assert_(
            np.array_equal(
                tslib.array_to_datetime(arr),
                np.array(
                    [
                        '2013-01-01T00:00:00.000000000-0000',
                        '2013-01-02T00:00:00.000000000-0000'
                    ],
                    dtype='M8[ns]'
                )
            )
        )

which gives an uniformative

AssertionError: False is not true

@bwignall, care to take another step? We could use a more informative
version of np.array_equal to added to pd.util.testing, borrowing from
the assert_series_equal function there perhaps, and a refactor to go with it.

[bwignall]

I will chip away at this more, @y-p. I was thinking of continuing on the assert_(x == y) theme, then circling back to other forms.

[hayd]

Just to point out, some of these aren't supported in 2.6 e.g. assertIsInstance, should we worry about that ? travis hasn't been able to test on 2.6 for a good while...

👍 on changing them all.

Note: they are backported in unittest2 - so we could import unittest2 as unittest in util/testing for py < 27?...

[jreback]

@hayd what do u mean
2.6 build tests

[jreback]

@bwignall leave this issue open?

[bwignall]

@hayd: tm.TestCase has versions of these, which should be API-compatible with the Python 2.7+ functions.

@jreback: I just went through the assertions again, and with the latest (#6580) PR, it looks like all of the straightforward changes have been made. There are still some assert_(...) statements, but those could all be changed to assertTrue(...) or assertFalse(...) at this point, if desired.

[jreback]

@bwignall that's for all the effort in this!
closing this issue but if u see things that need change pls submit additional PRs