Print

Print


We can discuss it further at slac, but unit testing at the class level is
generally considered important if we want to do extensive refactoring.
With multiple developers, unit testing ensures interface stability and
correct behavior so that development can continue on the encapsulated parts
while not breaking things for others.   Using xUnit will enable the
automated builds to capture and parse the unit test output and send out
emails etc to the developers that something is broken.  I'm not disputing
the importance of the integration tests, I'm just saying that the unit
tests could well afford to be more rigorous and an xUnit framework enables
that.  If and where we want to expend the effort is something we can sort
out at SLAC.

On Thu, Dec 13, 2012 at 10:27 AM, John Peterson <[log in to unmask]> wrote:

>
> not sure what you mean.  There is an existing basic framework for unit
> tests, and it already is run routinely for more than a year.  This doesn't
> really have anything to do with modularity or object-oriented design or
> automation as far as i understand what you are saying.  and as i have said,
> integration tests are much more important than unit tests, so this is why
> we came up with the current solution.
>
>
> On Dec 13, 2012, at 9:49 AM, James Chiang wrote:
>
> This is probably a discussion we should continue at the SLAC meeting.
> Andy had  a strong preference for using an xUnit framework.  As we add
> developers and move towards a more object-oriented design for the various
> components, regular unit testing, especially in the context of the
> automated builds will have lots of benefits, I believe.
>
> -Jim
>
> On Thu, Dec 13, 2012 at 9:47 AM, John Peterson <[log in to unmask]>wrote:
>
>>
>> Jim-
>>
>> one thing you probably have noticed is that validation/unittest.cpp has
>> 11 unit tests.  what isn't so obvious is the output of that is actually
>> parsed by the same program that makes all the validation plots and is part
>> of the validation pipeline.  this then makes a nice looking table of the
>> failures and successes of all of the unit tests and the 83 integration
>> tests.  so if you just make your test programs part of the
>> validation_pipeline and have the output simply the same as in unittest.cpp
>> (two columns:  name of test, and pass/fail) then it will automatically pick
>> them up.  it will even record the regression.
>>
>> so given that, it isn't clear to me we necessarily want a unit testing
>> framework, as the integration tests are more important and the framework
>> for that already has a basic unit testing structure embedded in it.  it is
>> possible to have a hybrid scheme where the existing unit tests are in a
>> standard framework, but the output is also handled by the integration
>> framework as well.  that seems a little bit over-engineered to me, but you
>> can possibly convince me.  but we should definitely discuss the merits.
>>
>> john
>>
>>
>>
>>
>> On Dec 13, 2012, at 11:59 AM, James Chiang wrote:
>>
>> Here's my update on the ancillary work:
>>
>> I added test code for FitsImage and PhosimParser classes:
>>
>> * test_fits_utils.cpp:  generates an image filled with random numbers,
>>   uses FitsImage to write to disk and FitsImage to read back in and
>>   verifies that the pixel values agree.
>>
>> * test_phosim_parser.cpp: Added tests for the old and new
>>   stringTokenize methods for testing and to illustrate usage.
>>
>> These test programs, as well as trim/test_trim.cpp, are written to be
>> easily incorporated into the xUnit framework for unit testing.  I
>> guess Andy C. would like us to use the Boost version,
>> which appears xUnit conforming.  I think this would be a good idea.
>> We need to refactor PhosimParser and FitsImage to rationalize the
>> various changes that Glenn, En-Hsin, and I have made.  This would be
>> good to discuss at the SLAC meeting.
>>
>> -Jim
>>
>>
>> On Wed, Dec 12, 2012 at 9:39 AM, James Chiang <[log in to unmask]>wrote:
>>
>>> Hi John,
>>>
>>> Unfortunately, Heather and I are in the DM stack working meeting today.
>>>  I can send an update later today on the stuff I did in ancillary.
>>>
>>> -Jim
>>>
>>>
>>> On Wed, Dec 12, 2012 at 8:12 AM, John Peterson <[log in to unmask]>wrote:
>>>
>>>>
>>>>
>>>> Usual phosim telecon today at 10 am PT, 1pm ET; agenda and call in info
>>>> below:
>>>>
>>>>
>>>> https://confluence.slac.stanford.edu/display/LSSTDESC/phoSim+Meeting+Agenda
>>>>   *12 Dec 2012*
>>>>
>>>>    - SLAC meeting (all)
>>>>    - Walkthrough (Wei, Heather, Joanne)
>>>>    - Recent software work
>>>>       - Ancillary (Jim)
>>>>       - instrument.cpp (Glenn)
>>>>       - observation.cpp/e2adc.cpp (En-Hsin)
>>>>       - photonloop.cpp (John)
>>>>    - Update on camera perturbation inputs (AndyR)
>>>>    - Update on lateral charge diffusion interface (En-Hsin)
>>>>    - Update on analytic forms of lateral charge diffusion patterns
>>>>    (AndyR)
>>>>    - AOB
>>>>
>>>>
>>>>  Wednesdays at 1pm ET
>>>>
>>>> Phone connection info:
>>>>
>>>>    - Dial Toll-Free Number: 866-740-1260 (U.S. & Canada)
>>>>    - International participants dial:
>>>>    Toll Number: 303-248-0285
>>>>    Or International Toll-Free Number:http://www.readytalk.com/intl
>>>>    - Enter your 7-digit access code, 5665526 followed by "#"
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> Use REPLY-ALL to reply to list
>>>>
>>>> To unsubscribe from the PHOSIM-DEV list, click the following link:
>>>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=PHOSIM-DEV&A=1
>>>>
>>>
>>>
>>>
>>> --
>>> James Chiang          SLAC, MS 29           home:   (650) 605-3346
>>> Fermi ISOC            2575 Sand Hill Rd     office: (650) 926-2930
>>>                       Menlo Park CA 94025   FAX:    (650) 926-5566
>>>
>>>
>>
>>
>> --
>> James Chiang          SLAC, MS 29           home:   (650) 605-3346
>> Fermi ISOC            2575 Sand Hill Rd     office: (650) 926-2930
>>                       Menlo Park CA 94025   FAX:    (650) 926-5566
>>
>>
>> ------------------------------
>>
>> Use REPLY-ALL to reply to list
>>
>> To unsubscribe from the PHOSIM-DEV list, click the following link:
>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=PHOSIM-DEV&A=1
>>
>>
>>
>
>
> --
> James Chiang          SLAC, MS 29           home:   (650) 605-3346
> Fermi ISOC            2575 Sand Hill Rd     office: (650) 926-2930
>                       Menlo Park CA 94025   FAX:    (650) 926-5566
>
>
> ------------------------------
>
> Use REPLY-ALL to reply to list
>
> To unsubscribe from the PHOSIM-DEV list, click the following link:
> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=PHOSIM-DEV&A=1
>
>
>
>


-- 
James Chiang          SLAC, MS 29           home:   (650) 605-3346
Fermi ISOC            2575 Sand Hill Rd     office: (650) 926-2930
                      Menlo Park CA 94025   FAX:    (650) 926-5566

########################################################################
Use REPLY-ALL to reply to list

To unsubscribe from the PHOSIM-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=PHOSIM-DEV&A=1