1 / 23

Seven Simple Steps to Unit Testing Happiness

Seven Simple Steps to Unit Testing Happiness. Steven Feuerstein PL/SQL Evangelist www.quest.com steven.feuerstein@quest.com . Eleven years spent writing ten books on the Oracle PL/SQL language. It's a scary world we live in.

Pat_Xavi
Download Presentation

Seven Simple Steps to Unit Testing Happiness

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Seven Simple Steps to Unit Testing Happiness Steven FeuersteinPL/SQL Evangelistwww.quest.com steven.feuerstein@quest.com

  2. Eleven years spent writing ten books on the Oracle PL/SQL language

  3. It's a scary world we live in.... • As a software professional, you know what goes on “behind the curtain.” • It's not a pretty sight, is it? "GEMS is a state of the art election management software package that runs on Microsoft's Windows operating system." -- http://www.diebold.com/dieboldes/GEMS.html

  4. Writing software is..... FUN!

  5. Testing software is..... Hard Work

  6. Buggy software is.... • Expensive • JUNE 25, 2002 (COMPUTERWORLD) - WASHINGTON -- Software bugs are costing the U.S. economy an estimated $59.5 billion each year. Of the total $59.5 billion cost, users incurred 64% of the cost and developers 36%. • Embarrassing • There are very few markets where "buyers are willing to accept products that they know are going to malfunction," said Gregory Tassey, the National Institute of Standards and Technology senior economist who headed the study. "But software is at the extreme end in terms of errors or bugs that are in the typical product when it is sold." • Deadly • But let's not dwell on that.....

  7. Wouldn't it be ever so nice if... • You could easily construct your tests... • You didn't have to wonder how to write the test code, how to perform complex tests. • You could easily run those tests... • And see the results, instantly and automatically. • You actually had the time to both construct and run those tests... • Writing and maintaining test code takes so much time! • You knew with certainty that your program worked, you didn't just guess or hope. • What a great feeling....

  8. Different types of testing • There are many types of testing: functional/system tests, stress tests, monkey tests, unit tests... • A "unit test" is the test of a single unit of code. • Also known as a programmer test • Unit tests are the responsibility of developers - that is, us, the people in this room. • Not fundamentally a job for the QA department, which generally focuses on functional and system tests.

  9. Testing vs Tracing vs Debugging • We tend to confuse these various terms and processes. Let's get them straight! • Testing is the process of determining if there are bugs in the code, and what test cases produce those bugs. • Tracing (a kind of code instrumentation) is the process of obtaining information about the application as it is running. • Debugging is the process of tracking down the specific lines of code that are causing a bug. • Oh...and then there is "trying" • "Let's try this and see if it works." • Trying is a poor substitute for logical analysis, debugging and real testing. Keep it to a minimum.

  10. Truth or Dare • How do you (or your team) unit test your PL/SQL code today? We use some form of automated testing software. We have a formal test process that we each follow, but otherwise a manual process. Everyone does their own thing and we hope for the best. Our users test our code.

  11. Typical Testing • DBMS_OUTPUT.PUT_LINE - unit testing mechanism of choice? BEGIN DBMS_OUTPUT.PUT_LINE (betwnstr (NULL, 3, 5, true)); DBMS_OUTPUT.PUT_LINE (betwnstr ('abcdefgh', 0, 5, true)); DBMS_OUTPUT.PUT_LINE (betwnstr ('abcdefgh', 3, 5, true)); DBMS_OUTPUT.PUT_LINE (betwnstr ('abcdefgh', -3, -5, true)); DBMS_OUTPUT.PUT_LINE (betwnstr ('abcdefgh', NULL, 5, true)); DBMS_OUTPUT.PUT_LINE (betwnstr ('abcdefgh', 3, NULL, true)); DBMS_OUTPUT.PUT_LINE (betwnstr ('abcdefgh', 3, 100, true)); END; There has got to be a better way! betwnstr.sf betwnstr.tst

  12. Moving towards a Better Way • Change from within: your code will not test itself. • Accept the responsibility and then be disciplined about it. • Change from without: you need better testing tools. • utPLSQL has been out there for years....an open source framework following in the footsteps of JUnit and other “XUnit” tools. • And now there is Quest Code Tester for Oracle. Hey, what about those seven steps?

  13. Application Preparation 7 X 1 Coding Conventions The Build Cycle Test and Review SQLAccess Debug To QA /Production ErrorMgt Build / Fix Code 6 Single Unit Preparation 2 3 4 5 DefineReq’ments ConstructHeader Define Tests Build Test Code Post-Production Post-Production Bug Report Enhance. Request My recommended development workflow

  14. 1. Application Preparation • One of the most wonderful things about starting a new project is the fantasy that we can “DO IT RIGHT” this time... • Don’t dive into coding right away. • “Best Practices” is all about deferred satisfaction. • Figure out at least these key aspects: • Coding conventions • SQL access • Error management

  15. 2. Describe required functionality • I need a variation of SUBSTR that will return the portion of a string between specified start and end locations. • Some specific requirements: • It should work like SUBSTR as much as makes sense (treat a start location of 0 as 1, for example; if the end location is past the end of the string, the treat it as the end of the string). • Negative start and end should return a substring at the end of the string. • Allow the user to specify whether or not the endpoints should be included.

  16. 3. Define the program specification • My specification or header should be compatible with all requirements. • I also self-document that the function is deterministic: no side effects. • I can (and will) now create a compile-able stub for the program. Why do that? • Because I can then fully define and implement my test code! FUNCTION betwnstr ( string_in IN VARCHAR2 , start_in IN PLS_INTEGER , end_in IN PLS_INTEGER , inclusive_in IN BOOLEAN DEFAULT TRUE ) RETURN VARCHAR2 DETERMINISTIC betwnstr0.sf

  17. TNT or TDD? 4. Define the test cases • Before I write any code, I will come up with as many of the test cases as possible -- and write my test code. • This is known as "test-driven development". TDD is a very hot topic among developers and is associated with Agile Software (http://agilemanifesto.org/) and Extreme Programming. • Putting aside the fancy names and methodologies, TDD makes perfect sense -- when you stop to think about it.

  18. The "driving" insight behind Test-Driven Development • For the most part, we see unit testing / code testing as something that is done after writing the program. • You work really hard building the program (with some intermittent "trying" to make sure it compiles and does something reasonable). • Then you think about testing -- and the things you think about testing are naturally related to what code you wrote. • There is a big problem with writing test code after writing our programs: • We subconsciously prejudice our testing to favor the stuff we are comfortable, and we think is working.

  19. Some of the test cases for BETWNSTR • Start and end within the string ("normal" usage) • Start of 0 • End past end of string • Null string, string of single character, 32767 len character • Null start and/or end • Negative start and end • Start larger than end (positive and negative) • Variations of the above with different inclusive values Don't be overwhelmed by the total number of cases. Start out with a representative sampling. You can always add from there.

  20. 5. Build the Test Code • The challenge (terror?) of the blank screen.... • How do I define the test cases? • How do I set up those tests? • How do I verify the results? • Let's see how Quest Code Tester for Oracle helps me tackle these challenges. • Define and maintain your test cases through a graphical interface, then let it do all the work. Time for some software "magic"

  21. Don't write test code – describe tests • Rather than write test code, use Quest Code Tester to describe the tests you need through a graphical interface. • It’s just like SQL vs. programming. • Quest Code Tester saves your descriptions in a test repository. • Critical information, especially for IT management • It generates a PL/SQL test package based on your descriptions and runs the test at your request, displaying the results.

  22. 6. The Build Cycle – Don’t forget “review” • Build – Test/Review – Fix. • It’s iterative, but that doesn’t mean it should be painful. • Automate as much as possible. • You’ve seen automated testing with Quest Code Tester. • You should also supplement peer code view with automated code analysis. • Options for automated analysis • Oracle PL/SQL warnings • Toad’s CodeXpert • PL/SQL Developer’s “lint checking”

  23. Change Your Testing Ways! • First of all, let's commit to testing. • Quest Code Tester for Oracle (and even open source utPLSQL) can make a dramatic difference in your ability to test and your confidence in the resulting code. • If you don't automate your testing, you don't stand a chance of writing robust, maintainable code. • Getting your hands on Code Tester • Commercial version and trial software available at www.quest.com/code-tester-for-oracle • Freeware version available at www.ToadWorld.com

More Related