TST: local test failures

[jbrockmendel]

Turning this into a tracker since more are turning up;.

• api.test_api.test_api (much less frequently than the others) (OSX, Ubuntu)
• frame.test_constructors.TestDataFrameConstructors.test_constructor_maskedrecarray_dtype (AttributeError: module 'numpy.ma' has no attribute 'mrecords', using numpy 1.16.4) (fixed in Assorted cleanups #26975)
• frame.test_constructors.TestDataFrameConstructors.test_constructor_mrecarray (AttributeError: module 'numpy.ma' has no attribute 'mrecords', using numpy 1.16.4) (fixed in Assorted cleanups #26975)
• series.indexing.test_datetime.test_index_unique (OSX) (fixed by TST: fix flaky test #27004)
• resample.test_resample_api.test_select_bad_cols
• io.formats.test_format.TestDataFrameFormatting.test_repr_html_long_multiindex
• io.formats.test_format.TestDataFrameFormatting.test_info_repr_html

[simonjayhawkins]

Do we have a tracker for these?

not that i'm aware of.

i'll just add these here for now.

i've see problems with pandas/tests/test_sorting.py::TestSafeSort::test_labels_out_of_bound[-1]
on a couple of occasions recently. https://dev.azure.com/pandas-dev/pandas/_build/results?buildId=12769

and just changed desktop machine to a different gen cpu and getting clipboard errors. haven't had chance to investigate further.

although it may be best if issues for different tests are logged separately?

[jbrockmendel]

The failure in series.indexing.test_datetime.test_index_unique seems to be about a fixture behaving creatively:

@pytest.fixture(scope='module')
def dups():
    dates = [datetime(2000, 1, 2), datetime(2000, 1, 2),
             datetime(2000, 1, 2), datetime(2000, 1, 3),
             datetime(2000, 1, 3), datetime(2000, 1, 3),
             datetime(2000, 1, 4), datetime(2000, 1, 4),
             datetime(2000, 1, 4), datetime(2000, 1, 5)]

    return Series(np.random.randn(len(dates)), index=dates)

def test_index_unique(dups):
        uniques = dups.index.unique()
        expected = DatetimeIndex([datetime(2000, 1, 2), datetime(2000, 1, 3),
                                  datetime(2000, 1, 4), datetime(2000, 1, 5)])
        assert uniques.dtype == 'M8[ns]'  # sanity
       tm.assert_index_equal(uniques, expected)

In all of the runs where this fails, the output shows that dups.index includes datetime(2000, 1, 6), which shouldn't be there according to the fixture.

Below in test_duplicate_dates_indexing the test sets ts[datetime(2000, 1, 6)] = 0 which, if the fixture is re-using the same object, would explain it. It looks like we just recently started randomizing the order of the tests, which would explain this.

[simonjayhawkins]

Below in test_duplicate_dates_indexing the test sets ts[datetime(2000, 1, 6)] = 0 which, if the fixture is re-using the same object, would explain it.

scope='module' means the fixture is created once per module and reused. The default is per test function.

using scope='module' or even scope='session' could be a potential benefit if we had immutable DataFrames.

for the moment though we probably shouldn't be using scope on fixtures.