[datatable-help] Streamlining unit tests with test_that

[Steve Lianoglou]

Hi,

On Thu, Dec 23, 2010 at 4:59 PM, Matthew Dowle <mdowle at mdowle.plus.com> wrote:
> Hi Steve,
>
> Sorry not had time to look at this yet. Hoping to soon. Let me know if
> you're held up. It's high priority my side too as I'd like to fix
> the .Depends issue, the 2 outstanding bugs, get cedta sorted and release
> those few things onto CRAN soon. S4 tests would be nice to include.

I'm not held up really, I'm just using my current modified version
until you guys have time to give a tentative heads up for me to push
these back into the package.

> One thought though .. how would we know the ported tests correctly fail
> when they should?  Or perhaps it's easier to ask ... how would we know
> the ported tests fail in the same conditions the old tests fail?

There are functions that test to ensure a code block fails, like:

expect_that(log("a"), throws_error("Non-numeric argument")) ## or
expect_error(log("a"), "Non-numeric argument")

Is that what you're asking? Or are you asking how we can test/ensure
that the tests have been "ported over" faithfully?

> So I'm thinking we should keep the old test.data.table() there running
> even if it's just locked down. We could put new tests into test_that
> going forward (starting with S4) and that would save you the time of
> porting. Would that work?

That can work too, if you like. I was thinking that porting the tests
over, though, might encourage/ensure further tests to use testthat
since they might function as examples on how one tests different
things.

Still, we can start by doing what you suggest and slowly incorporate
the older tests into this framework if anyone feels it'd be better.

Really -- whatever you like, you're driving this boat.

-steve

-- 
Steve Lianoglou
Graduate Student: Computational Systems Biology
 | Memorial Sloan-Kettering Cancer Center
 | Weill Medical College of Cornell University
Contact Info: http://cbio.mskcc.org/~lianos/contact