[GSoC-PortA] PortfolioAnalytics Testing

[Joshua Ulrich]

While you're working on unit testing, also think about performance
benchmarking.  I've wanted to write something like Wes McKinney's
(Python pandas author) vbench package for R ever since I was able to
make large performance improvements to quantstrat.  I'm not suggesting
you work on building that functionality, but rather than you keep
notes on which functions should be monitored for performance
regressions.
--
Joshua Ulrich  |  about.me/joshuaulrich
FOSS Trading  |  www.fosstrading.com


On Sun, Dec 1, 2013 at 6:21 PM, Ross Bennett <rossbennett34 at gmail.com> wrote:
> Sounds good, I'll get started with tests for the demos and add tests for
> specific functions only as needed. I like the idea of 'integrated testing'
> using the demo files. It will also be a good opportunity to look closer at
> the demos to make sure each demo is comprehensive and serves a specific
> purpose.
>
> Thanks for the guidance!
>
> Ross
>
>
>
> On Sun, Dec 1, 2013 at 2:46 PM, Brian G. Peterson <brian at braverock.com>
> wrote:
>>
>> As you say, both approaches have merit.
>>
>> I would suggest starting with the demos, as this will test a broad set of
>> functionality, and provides 'integration testing' for the entire package.
>> It also minimizes test code to write at first.
>>
>> I agree that testing specific functions and inputs may be 'more robust',
>> but it will also take (significantly) more time to design a test plan and
>> suite of separate tests.  I don't want to discourage that by any means, but
>> I would want to get test coverage for the functionality in the demos first.
>>
>> Regards,
>>
>> Brian
>>
>>
>> On 12/01/2013 02:29 PM, Ross Bennett wrote:
>>>
>>> With the optimization I've been doing in constrained_objective and now
>>> with the ROI changes, I am really starting to appreciate a more formal
>>> testing process instead of running demos and seeing what fails. I've
>>> started playing with the testthat package and really like it.
>>>
>>> I've had a look at quantstrat and plyr to see how the testthat package
>>> is used. The main difference is that quantstrat uses the demo files
>>> whereas plyr uses manually written test files. There are pros and cons
>>> to both approaches... using the demos as the tests minimizes duplicate
>>> code, but manual tests allow us to test specific things we may not
>>> need/want in the demos.
>>>
>>> I want to write some tests using testthat to include in
>>> PortfolioAnalytics, but would like your guidance on what framework or
>>> approach to use before I begin.
>>
>> _______________________________________________
>> GSoC-PortA mailing list
>> GSoC-PortA at lists.r-forge.r-project.org
>> http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta
>
>
>
> _______________________________________________
> GSoC-PortA mailing list
> GSoC-PortA at lists.r-forge.r-project.org
> http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/gsoc-porta
>