Testing & should i do it

Testing & should i do it

• 1.
  Testing & shouldI do it? Martin Sykora (M.D.Sykora@lboro.ac.uk)
• 2.
  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’
• 3.
  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.
• 4.
  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…
• 5.
  Recap – typesof 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
• 6.
  Recap – Basic(common) Debugging That’s not enough thought! 1. Think of some appropriate test data sets: extreme values, normal data, bad data Just some thoughts 2. Breakpoints: Many Compilers allow to insert breakpoints -3. QualityAssurance departments Displaying variables and markers: - Industry avg 15-50 errors /1000lines (it was #if DEBUG suggested some projects have 10x more) [SteveMcConnell1993] CommdanLine.Write(‘vector[’+i+’]=’+vec); - PhD student (often) 1man team (if ur lucky 2-3) #endif - Correctness is important: adds confidence to the code can reuse confidently
• 7.
  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,…)
• 8.
  Other Productivity Tools  dropbox, spideroak, online file- publishing/sharing collaboration tools  svn, cvs,… (code repository / version tracking soft.)  bug tracking tools…
• 9.
  Test Plan! …keepsyou 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
• 10.
  Risk Control! …prioritisedebugging
• 11.
  Keep in mind!…a developers’ check list 1. Use Unit Tests 2. Create a list of critical requirements so you can perform a ‘smoke test’ on each new build 3. Keep a written list of requirements and test to make sure the application meets each one 4. Set code aside (for a few days) before performing functional testing on it 5. 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.
• 12.
  Summary  Don’t beignorant 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
• 13.
  Recommended Reading