thats also something that i had seen when testing the bti. in one case i still had an unpacking bug + incorrectly reordered data and one of the tests did not fail, although you could clearly see it with your eyes. good you bring up this issue.

On 31.01.2013,  at 03:47, Eric89GXL <notifications@github.com> wrote:

> In mne/fiff/tests/test_raw.py:
> 
> > @@ -54,10 +76,10 @@ def test_multiple_files():
> >      all_raw_1 = concatenate_raws(raws, preload=False)
> >      assert_true(raw.first_samp == all_raw_1.first_samp)
> >      assert_true(raw.last_samp == all_raw_1.last_samp)
> > -    assert_array_almost_equal(raw[:, :][0], all_raw_1[:, :][0])
> > +    assert_allclose(raw[:, :][0], all_raw_1[:, :][0])
> @agramfort I think we should eventually migrate many of our testing calls to assert_array_almost_equal() to assert_allclose(). They both have valid and appropriate uses in different contexts, but I think that some of the times we've used assert_array_almost_equal() we've actually wanted to say assert_allclose(). In this example, assert_array_almost_equal would not check the meg channels at all, actually, since they are all fewer than 7 decimals. Think of an MEG channel that got blown up by a factor of 1e5, for example, this test passes:
> 
> np.testing.assert_array_almost_equal([1e-11], [1e-6])
> Anyway, just something to consider when we go through and design tests moving forward. I've modified the tests in a way I think sane in this version of test_raw.py, see what you think.
> 
> —
> Reply to this email directly or view it on GitHub.
>