Detecting Bugs Using Assertions

Detecting Bugs Using Assertions

In this article, Ben Scribner discusses the problem of bugs in software and the various types of errors they can create such as unexpected errors, hardware failures, loss of data, and incorrect data formatting

About Detecting Bugs Using Assertions

PowerPoint presentation about 'Detecting Bugs Using Assertions'. This presentation describes the topic on In this article, Ben Scribner discusses the problem of bugs in software and the various types of errors they can create such as unexpected errors, hardware failures, loss of data, and incorrect data formatting. The key topics included in this slideshow are . Download this presentation absolutely free.

Presentation Transcript

Slide1Detecting BugsUsing Assertions Ben Scribner

Slide2Defining the Problem Bugs exist  Unexpected errors happen  Hardware failures  Loss of data  Data may exist but may be in the wrong format  Complex code sometimes has unforeseen effects  Users enter incorrect data

Slide3The Familiar Solution Standard error checking  Check if a file exists  Make sure variables are defined  Ensure that data is in the correct format  Ways of handling errors  Exceptions  Messages to the user  Form Validation Method

Slide4Error Checking Limitations Cannot check everything  Already takes up a lot of code, using for every situation is impractical  Situations most people do not use error checking  Function output  Default case in switch statement  Else in an if statement  Pre / Post Conditions

Slide5To Sum Up the Problem Programmers assume many things to be true  Often these assumptions are proven incorrect  Assumption errors can be difficult to catch  These errors can cause other modules to fail making the problem difficult to trace

Slide6Is There Another Method? Assertions  A Boolean expression that is true if an assumption is correct  Could be a comment  Often used as actual code to test conditions  Strictly used for testing

Slide7What Does It Look Like?<cf_assert assertion = “ myAge as a: IsNumeric( |a| ); |a| GT 0; |a| LT 100 myName as b: IsDefined( ‘|b|’ ); Len( |b| ) GT 4”> <cf_assert assertion = “URL.test as u: IsDefined( ‘|u|’ )”> <cf_assert assertion = “FORM.test as f: IsDefined( ‘|f|’ )”> <cf_assert assertion = “todayDate as t: IsNumericDate( |t| )”> <cf_assert assertion = “myArray as a: NOT ArrayIsEmpty( |a| )”>

Slide8How Do I Put One Together?Assertion := <cf_assert assertion = “Statement”> Statement := any_variable as any_char: Boolean | Statement Statement ex: myVar as v Boolean := (statement returning true or false) | Boolean; Boolean Note: the character representing the variable is always referred to using pipes ex. |a|

Slide9How Is It Implemented? cf_assert sends whole expression to assert.cfm  assert.cfm is in the custom tags folder  It parses the expression and evaluates it  If expression = true, assertion does nothing  If expression = false, assertion throws an exception  Exceptions can be caught manually, or Coldfusion will catch them and display the errors

Slide10What Does an Error Return? Without exceptions: <cfset myVar = “Ben”> <cf_assert assertion = “myVar as v: IsNumeric( |v| )”>  When I test the code: Error Occurred While Processing Request The assertion IsNumeric( myVar ) failed

Slide11What Does an Error Return? (cont.) With exceptions <cfset myVar = “Ben”> <cftry> <cf_assert assertion = “myVar as v: IsNumeric( |v| )”> <cfcatch type=“any”> your variable is not a number </cfcatch </cftry>  When I test the code: your variable is not a number

Slide12Database ExampleData: PID displayOrder   1          5   3          2   2          7   9          6 <cfquery name=“select” datasource=“myDatabase”> Select * From myTable Order By displayOrder </cfquery>

Slide13Database Example (cont.)<cfset array=ArrayNew(2)> <cfloop query=“select”> <cfif CurrentRow GT 1> <cfset dispOrd=array[CurrentRow – 1][2]> <cf_assert assertion = “array as a: #select.displayOrder# GT #dispOrd#”> <cfelse> <cf_assert assertion = “array as a: ArrayIsEmpty( |a| )”> </cfif> <cfset array[CurrentRow][1] = #select.PID#> <cfset array[CurrentRow][2] = #select.displayOrder#> </cfloop>

Slide14Switch ExamplemyVar can be either 1 or 2, nothing else <cfswitch expression=“#myVar#”> <cfcase value=1> <cfinclude template=“myPage1.cfm”> </cfcase> <cfcase value=2> <cfinclude template=“myPage2.cfm”> </cfcase>

Slide15Switch Example (cont.)<cfdefaultcase> <cf_assert assertion = “myVar as v: |v| IS 1 OR |v| IS 2”> </cfdefaultcase> </cfswitch>  Sometimes it is assumed that there is no need for a default case. This is a good place for an assertion

Slide16Form ExamplePage1.cfm: <Form Action=“Page2.cfm” Method=“post”> Name: <Input Type=“text” Name=“name”><br> Date of Birth: <Input Type=“text” Name=“dob”><br> <Input Type=“submit” value=“Calculate”> </Form>

Slide17Form Example (cont.)Page2.cfm <cfmodule template=“/wwwAdmin/CF_Tags/Validate_Forms_XML.cfm” FDF_URL=“/benTest/page1.xml”> <cf_assert assertion = “ as n: IsDefined( ‘|n|’ ); Len( |n| ) GTE 3 FORM.dob as d: IsDefined( ‘|d|’ ); IsNumericDate( |d| )”> <cfoutput> Hello, you are #DateDiff(‘YYYY’, FORM.dob, Now())#. </cfoutput>

Slide18Assertion Benefits Can be used to:  Catch logic errors  Check results of an operation  Detect errors soon after they occur  Make statements about the code that are guaranteed to be true  Serve much the same purpose as comments

Slide19How They Should Be Used Solely for testing  They are designed to help the programmer find bugs, not to aide the flow of execution  Should be turned off in production code  assert.cfm can be an empty file on production, so there is no need to comment assertions out  Should be used in any situation where the programmer assumes something to be true

Slide20The Other Side Assertion Limitations  Errors in assertion logic can lead to misleading problems  They can impact performance  Some cases are difficult to test for, some assertions may never execute  They take time to write

Slide21What Does All This Mean to Me? The use of assertions can lead to well-tested, correct code  They self-document the code, allowing others to understand modules more efficiently  Programmers will better understand pre/post conditions  Some bugs may be caught before the code is even tested

Slide22In Conclusion Assertions are a great way to aide testing  They are by no means a “Silver Bullet”  Using them will not eliminate all bugs  Questions?