testing & should i do it
DESCRIPTION
A short presentation I gave to our PhD groupTRANSCRIPT
Testing & should I do it?Martin Sykora ([email protected])
Why this talk
I could talk about my own research but I decided to talk about something that might be more helpful
Some experience (PhD experience)
Hope you learn something today
Motivated by Mike Gunderloy’s excellent book ‘Coder To Developer’
Introduction
• As PhD Students in Computer Science, most of us (at some point) will have to write-up our own code to:
- test algorithms- investigate / integrate / transform datasets- perform various tasks indispensable to our
PhD work (batch jobs, …)“Whatever it is we must do, it is essential that the code
executes correctly!”However it seems that a lot of such (PhD)code is
hacked together (most often) in a rush (to get exper. results)!
Additionally little in ways of structured approach and emphasis on rigorous testing would ever take place.
Introduction
• In this talk I want to focus on ways of how to avoid writing buggy code and ensuring what we produce isn’t riddled with errors.
• So let’s dive straight into it…
Recap – types of Debugging
1. Black box: you do not know / care how the program does something, you only know what the program is supposed to do!
2. White box: opposite of Black box testing
3. Unit testing: testing of individual modules
4. Integration: testing of the sub-systems and the system as it is drawn together. Do components interact correclty
5. System: final testing of the complete system
6. Regression: after significant changes were made to the system, to ensure that new bugs not present in previously have crept in (as a consequence of the changes).
-Stress Testing, Beta testing, Acceptance testing, Smoke testing…
Recap – Basic (common) Debugging
1. Think of some appropriate test data sets: extreme values, normal data, bad data
2. Breakpoints: Many Compilers allow to insert breakpoints
3. Displaying variables and markers: #if DEBUG
CommdanLine.Write(‘vector[’+i+’]=’+vec);
#endif
That’s not enough thought!
Just some thoughts
- QualityAssurance departments- Industry avg 15-50 errors /1000lines (it
was suggested some projects have 10x more) [SteveMcConnell1993]
- PhD student (often) 1man team (if ur lucky 2-3)
- Correctness is important:adds confidence to the codecan reuse confidently
Things to do! …to fight this
1. Code Defensively
2. Automated unit testing (Junit [Erich Gamma & Kent Beck], Nunit,…)
1. Mock Objects: real object doesn’t exist, real object takes a long time to do its work, real object is hard to set up or clean up after, real object depends on unreliable resources (networking connectivity), real object requires user input
3. Test Driven Development [Kent Beck’s Test-Driven Development: By example, 2003]
4. Your MUST have a Testing PLAN!
5. Database store (instead of many csv files,…)
Other Productivity Tools
dropbox, spideroak, online file-publishing/sharing collaboration tools
svn, cvs,… (code repository / version tracking soft.)
bug tracking tools…
Test Plan! …keeps you focused on the goal
1. Your MUST have a Testing PLAN!
2. Bug Triage: By Design
Duplicate
Postponed
Not reproducible
Won’t fix
Reassigned
Fixed
Risk Control! …prioritise debugging
Keep in mind! …a developers’ check list
1. Use Unit Tests2. Create a list of critical requirements so you can perform
a ‘smoke test’ on each new build3. Keep a written list of requirements and test to make
sure the application meets each one4. Set code aside (for a few days) before performing
functional testing on it5. If you think of something that might go wrong while
you’re in the middle of coding, enter it as a bug in your bug-tracking system. This will help you remember to test the problem when you are not wearing your coding hat.
6. ‘Blind spots’, when you simply don’t notice how your application is subtly failing, or to avoid testing something absurd because you know that it doesn’t make sense.
Summary
Don’t be ignorant towards rigorous testing!
Anything you code – it’s a MUST to have a test plan (step by step) – think of every module and major function (the bug likely bits of code).
Questions
Recommended Reading