2013 Spring Meeting of Korean Meteorological Society / KIAPS Workshop
Developing I/O module of KIAPS Framework
with Test-Driven Development
Sang-Yoon Jun, Ki-Hwan Kim, Junghan Kim, In-Sun Song,
Seoleun Shin, Youngsu Lee, and Dongchan Joo
Systems Development Team,
Korea Institute of Atmospheric Prediction Systems
Numerical model is a Complicated Software
module relationship diagram for CAM-SE shallow water model
Developing complicate software: Software Engineering
The IEEE Computer Society tried to define and clarify the software engineering
via the Software Engineering Body of Knowledge (SWEBOK) project .
Software Requirement
Software Design
Software Configuration Management
Software Construction
Software Engineering Management
Software Testing
Software Engineering Process
Software Maintenance
Software Engineering Tools and Methods
Software Quality
Numerical model development utilizes
Object-Oriented Programming, Component Based Programming,
Framework-Based Development, CVS, SVN, …
Software testing and conventional approach
Tests that verify software functionality
- detects unintended changes
- improves developer confidence
- decreases risk from change
Clune, 2012
Write
Compile
Run
Test
code
code
code
code
Testing code is usually performed
by checking result (log or visualized output)
under different conditions
or inserting validating routines into source
Software Testing – testing complicated software
Increasing in a number of
implementation layer yields a
complexity of software and a cost of
verification/validation.
Conventional testing method can be
painful for the complicate software .
Solution for testing complicated software: Unit-Testing
Add tests to each unit
functionality (module, or class),
and check reliability of software
through these unit-tests.
Unit-testing could help testing
complicate software.
As software becomes larger and more complex, tests as well.
Writing and maintaining tests could be another heavy task.
change a paradigm: Test-Driven Development
Conventional Development Process
write
compile
run
test
code
code
code
code
Test-Driven Development (TDD)
Write test
Integrates developed
module to other module
The TDD gives benefits:
- High reliability
- Excellent Test Coverage
- Less time spent debugging
- Productivity
- Tests act as maintainable
documentation
that fails
Unit-Testing and Test-Automation
are the keys for
Test-Driven Development
Make test
Refactor code
code to work
normally
Solution for TDD: xUnit Testing Framework
Test written in language of target
software
Organize tests
Provide verifying functions
Automate tests
Assertion
Test Case
Test Fixture /
Context
Test Suites
xUnit testing framework provides functionalities based on each language
ABAP, ActionScript / Adobe Flex, Ada, AppleScript, ASCET, ASP, BPEL, C, C#, C++, Cg, CFML
(ColdFusion), Clojure, Cobol, Common Lisp, Curl, Delphi, Emacs Lisp, Erlang, Fortran, F#, Groovy,
Genexus, Haskell, HaXe, HLSL, ITT IDL, Internet, Java, JavaScript, Lasso, LaTeX, LabVIEW, LISP, Lua,
MATLAB, MySQL, .NET programming languages, Objective-C, OCaml, Object Pascal (Free Pascal),
PegaRULES Process Commander, Perl, PHP, PL/SQL, PostgreSQL, PowerBuilder, Progress 4GL,
Prolog, Python, R programming language, Racket, REALbasic, Rebol, RPG, Ruby, SAS, Scala, Scilab,
Scheme, Shell, Simulink, Smalltalk, SQL, TargetLink, Tcl, TinyOS/nesC, Transact-SQL, TypeScript,
Visual FoxPro, Visual Basic (VB6), Visual Lisp, XML, XSLT
xUnit testing framework for Fortran: pFUnit
pFUnit is a Fortran testing framework created by developer from National
Aeronautics and Space Administration (NASA) and The Analytic
Sciences Corporation (TASC).
Distributed under NASA Open Source Agreement (NOSA)
pFUnit targets at software written in Fortran
- Supports using TDD in standard Fortran (INTEL, GNU, NAG, IBM, and PGI)
- Supports testing of parallel software based on MPI
- Extensive support for multidimensional FP arrays
Used to develop some packages in NASA GISS-E model
Available at: http://sourceforge.net/projects/pfunit/
Developing KIAPS I/O module with pFUnit
Requirement of I/O module
- provide interface routines, which read input and write output, to other
module.
- I/O methods could be changed and refined in order to increase model
performance under various runtime condition.
Design of I/O module
divide I/O module into 2 levels :
high-level layer which provides interface to other modules, and low-level layer
which handles input and output files.
First Step: Writing test
$> make unittests
make[1]…
…
…
mpirun -n 4 ./tests.x
4 failures in Test::KiapsIoModuleTest::testDefineDimension:
- (pe:
0) (pe:
0) rtion failed:
Strings of unequal length.
Differences begin at position 5.
Expected: "time_invalid"
but found: "time"
SUBROUTINE
TestInitIoSystems
- (pe:
1) String
assertion failed:
PROGRAM TestDriverMain
Strings of unequal length.
…
SUBROUTINE
TestDriverMain
DifferencesTestCreateFile
begin at position 5.
suite_all = TestSuite('Test')
Expected: "time_invalid"
SUBROUTINE
but found: TestWriteState
"time"
CALL add(suite_all,
…
- (pe:
2) String assertion failed:
io_tests())
CALL AssertEqual(l_ierr,
Strings
of unequal length.
IO_NO_ERROR)
Differences begin at position 5.
TestKiapsIoModule
CALL Run(suite_all, result)
…Expected: "time_invalid"
END
but SUBROUTINE
found: "time"
smy_stmt = Summary(result)
- (pe:
3) String assertion failed:
…
SUBROUTINE
Strings of TestCloseFile
unequal length.
END PROGRAM TestDriverMain
Differences begin at position 5.
SUBROUTINE
Expected: TestFinIoSystems
"time_invalid"
but found: "time"
9 run, 9 failed 0.08 seconds
make[2]: …
make[1]: …
$> _
These tests will be failed.
Second Step: Make test to work normally
TestDriverMain
KiapsIoModule
TestKiapsIoModule
$> make unittests
make[1]…
…
PioIoModule
mpirun -n 4 ./tests.x
9 run, 0 failed 0.08 seconds
make[2]: …
make[1]: …
$> _
Make test to pass by
implementing I/O Module.
Third step: Refactor codes
KiapsOutputModule
KiapsInputModule
TestDriverMain
KiapsCommonIoModule
TestKiapsIoModule
$> make unittests
make[1]…
…
PioIoModule
mpirun -n 4 ./tests.x
9 run, 0 failed 0.08 seconds
make[2]: …
make[1]: …
$> _
We can refactor and refine
code because passing tests
guarantee normal working
of I/O module.
Further works with the TDD
KiapsHistoryModule
OutputVariableManagerModule
Other Module
KiapsOutputModule
KiapsInputModule
KiapsCommonIoModule
PioIoModule
pNetCDFIoModule
TestDriverMain
TestKiapsIoModule
Summary
The Systems Development Team in KIAPS develops I/O modules by
adopting Test-Driven Development.
Test-Driven Development with pFUnit testing framework gives:
- High reliability
- Excellent Test Coverage
- Less time spent debugging
- Flexibility
We consider using TDD to develop other modules in KIAPS model.
Thank you for your attention!
Descargar

TDD to KIAPS Framework