[Bioc-devel] writing unit tests for functions in an initializer

Hervé Pagès hpages at fredhutch.org
Thu Sep 28 19:30:09 CEST 2017


Yep. And w.r.t. empty objects, make sure new("MyClass") works and
returns a valid object. This should produce an "empty" object.

Note that the explicit constructor function should be named as the
class itself (e.g. MyClass()). It's up to you to decide whether
it should support being called with no arguments (and behave just
like new("MyClass") in that case).

Cheers,
H.

On 09/28/2017 10:13 AM, Michael Lawrence wrote:
> I agree with Kasper. You are better off just leaving initialize() to
> its default implementation. Violating that abstraction for the purpose
> of testing is only going to put your software more at risk, defeating
> the purpose of testing.
>
> Overriding initialize() makes it do more than just set slots, but then
> there's no simple way to just initialize an object with specific slot
> values.
>
> Put another way, if you think of software as an onion of abstraction
> layers, initialize() is at the bottom, and making it do more raises it
> up a level, which is disruptive.
>
> Michael
>
> On Thu, Sep 28, 2017 at 10:00 AM, Kasper Daniel Hansen
> <kasperdanielhansen at gmail.com> wrote:
>> Ok, this is answering a different question, but the recommendation is to
>> avoid spending time on the initialize method and instead write am explicit
>> constructor function.
>>
>> On Thu, Sep 28, 2017 at 10:48 AM, Zach Skidmore <zskidmor at wustl.edu> wrote:
>>
>>> Hi All,
>>>
>>> I maintain the GenVisR package and am currently converting it to S4
>>> classes. I'm running into a problem however when writing unit tests for
>>> functions within the initalizer. What I really need is a "mock" object of
>>> the class for which the initializer unit tests are being performed but
>>> which hold no data. This will allow me to step through the initializer "sub
>>> functions" and write tests for each one. The problem is I don't see a way
>>> in the S4 system to create a mock object. I've found this post that will do
>>> what I want https://urldefense.proofpoint.com/v2/url?u=http-3A__r.789695.n4.nabble.com_Using-2Da-2Dmock-2Dof-2Dan-2DS4-2Dclass-2D&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=E7E1IgOkbh8tTHxd1nMRLxG0TSoO1bPovE9KbCJqkcc&s=09aZdeqljGIeuqC3xMM9jZiWiYiGk8FLCdpazy2oAZ8&e=
>>> td4728547.html, however when using this solution R CMD CHECK throws
>>> errors:
>>>
>>> * checking dependencies in R code ... WARNING
>>> Unexported object imported by a ':::' call: ‘methods:::C_new_object’
>>>    See the note in ?`:::` about the use of this operator.
>>>    Including base/recommended package(s):
>>>    ‘methods’
>>> * checking S3 generic/method consistency ... OK
>>> * checking replacement functions ... OK
>>> * checking foreign function calls ... WARNING
>>> Foreign function call to a base package:
>>>    .Call(methods:::C_new_object, ...)
>>> Packages should not make .C/.Call/.External/.Fortran calls to a base
>>> package. They are not part of the API, for use only by R itself and
>>> subject to change without notice.
>>>
>>> I'm wondering if anyone has any ideas on the best way to handle this. I
>>> suppose i could create a "test" flag within the initalizer that would
>>> create an empty object of that class and use that but it seems hacky to do
>>> this.
>>>
>>> thanks!
>>> Zach
>>>
>>> ________________________________
>>> The materials in this message are private and may contain Protected
>>> Healthcare Information or other information of a sensitive nature. If you
>>> are not the intended recipient, be advised that any unauthorized use,
>>> disclosure, copying or the taking of any action in reliance on the contents
>>> of this information is strictly prohibited. If you have received this email
>>> in error, please immediately notify the sender via telephone or return mail.
>>>
>>>          [[alternative HTML version deleted]]
>>>
>>> _______________________________________________
>>> Bioc-devel at r-project.org mailing list
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=E7E1IgOkbh8tTHxd1nMRLxG0TSoO1bPovE9KbCJqkcc&s=oK333tgtd4c9CizAAOplesAb4w3JlPGst73xLkq2Ze0&e=
>>
>>          [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> Bioc-devel at r-project.org mailing list
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=E7E1IgOkbh8tTHxd1nMRLxG0TSoO1bPovE9KbCJqkcc&s=oK333tgtd4c9CizAAOplesAb4w3JlPGst73xLkq2Ze0&e=
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwIGaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=E7E1IgOkbh8tTHxd1nMRLxG0TSoO1bPovE9KbCJqkcc&s=oK333tgtd4c9CizAAOplesAb4w3JlPGst73xLkq2Ze0&e=
>

-- 
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fredhutch.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319



More information about the Bioc-devel mailing list