Print

Print

jim,

again, there is nothing wrong with unit testing at the class level within the current context.  hold on, i'll show you with your test programs...give me a sec....

john

On Dec 13, 2012, at 1:31 PM, James Chiang wrote:

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:

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:


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