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

[Michael Lawrence]

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 http://r.789695.n4.nabble.com/Using-a-mock-of-an-S4-class-
>> 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://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>         [[alternative HTML version deleted]]
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel