Book Section
-----
TY JavaScript 3rd Ed.
Teach Yourself JS 1.5
Teach Yourself DHTML
Teach Yourself JS 1.3
LLWW: JavaScript

General Section
-----
Discussion Forum
Articles / Tips
JavaScript Links
About the Author
Privacy Policy
Contact Me



Other Sites
-----
Website Workshop
JavaScript Weblog

JavaScript Workshop Forums

 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
Debugging - A Case Study.

 
Post new topic   Reply to topic    JSWorkshop Forum Index -> Articles
View previous topic :: View next topic  
Author Message
phil karras
Senior Member
Senior Member


Joined: 15 Jul 2002
Posts: 1750
Location: MD

PostPosted: Mon Nov 18, 2002 11:11 am    Post subject: Debugging - A Case Study. Reply with quote

This will be a case study of how I debugged a large multi-file JavaScript database application. Perhaps from this case study you will be able to learn how to debug your code in a systematic way that will help you in all future debugging endeavors. The first advice I give is to never write a large script before testing each section as you go. I did this in all of these files and came across a number of statements like, "// working 05/15/2002." Unfortunately, what happened to me will no doubt happen to some of you from time to time also.

I have a multi-file JavaScript database application. I use a base HTML file, caret.htm, and two script files: ReadFile.js and Pfind.js.

ReadFile.js reads in the database file and parses it. It looks for anchors and creates a <select> drop-down list of all the anchors found, the names of which are placed into another array, and then creates the innerHTML to display the drop-down list, the DB files list, and the data on the page.

Pfind.js has the functions to do all the DB searches, build the results page, and open a new window to display the results.

I have had no problems with this application for months and wrongly thought it was bug free.

While attending a meeting where I was demonstrating the application in IE, I decided to demo it in Netscape 6.1 as well. Everything worked except the anchor drop-down select list. It would not jump to the selected anchor. It looked like the problem was that the onChange event was not firing.

I was more than a little disappointed about having to debug such an intricate family of functions in multiple script & HTML files.

Now when debugging a large complicated script I have often advised others to cut it down to the basics, so this is exactly what I did. I spent an hour or more just planning a debugging strategy. I also decided to document my progress as a possible teaching tool.

The strategy I settled on was to...
1. Create a simple HTML and minimal JavaScript file to first test the simple concept of a select list passing its value to a JavaScript function.
2. Use more JavaScript to build the select list and use innerHTML to place it on the page.
3. Compare the test implementation with the original database to see if I did anything differently. If so, then test to see if the difference(s) caused the problem.
4. Continue with 2 and 3 above as needed up to a test file using both the Pfind and ReadFile JavaScript libraries, if needed.

I started by creating a new program, OnChng01.htm, to test just the concepts used in all the other files using standard HTML and as little JavaScript as possible in the one HTML file only. I had removed the concept of building the <select> list on-the-fly and putting it in using just HTML for this initial test. This worked just fine.

Next I added the building of the innerHTML to form the <select> drop-down, but with a hard coded JavaScript array; this too worked fine.

I then looked at the two files (caret.htm and OnChng02.htm) to see if I could see any difference between the test code and the original ReadFile & HTML-file sections of code. I noticed that I had used the name "Anchors" in the DB.html file. So, I changed the name to <select name='Anchors'> and the test code stopped working!

I changed all the references to 'Anchors' to 'MyAnchors' in the caret.htm, Pfind, and ReadFile - the JS files. Unfortunately the fix was not to be so easy for the DB application. It still did not work. However, now the onChange event was firing. I could tell this because the onChange was calling a function to get the list value. The first statement in the function was an alert statement to display this value. While the alert was now popping up, it was saying that there was no select-list object. Yet the list was there on the page and I could select from it. When I tried to get the value I was told that document.Lookup.MyAnchors (the <select name='MyAnchors'> tag/object) was undefined!

I went back to the files to see if there were any other differences that I was overlooking. There was one more:

In the test file I had a section like this:
Code:

      <form ACTION="" name='Lookup'>
        <div id='MoreHere'>
         <select>
           <option value='====='>=====</option>
           <option value='Phil01'>Phil01</option>
         </select>
        </div>
      </form>

but in the DB application the code was:
Code:

      <form ACTION="" name='Lookup'>
        <div id='MoreHere'>
        Looking for <b>Select A Search</b> items...
        </div>
      </form>

So, I swapped the two. I placed the <select> section from the test file into the DB (caret.htm) file, and then I removed the <select> from the test (onChng03.htm) file.

The results of this double test were that the DB application still did not work and the test program still worked fine. This showed that the innerHTML to form the select list worked fine with or without an initial <select> list in the HTML <div> section.

With these results there was nothing left to do but to make a new test program that used all of the JS files and functions being used by the caret.htm file, DB application. This was because at this point I had proven that everything worked when the innerHTML code was built up inside the HTML file. I now needed to test the concept of reading in a DB file and building the innerHTML code for the <select> box from the information in the DB using the JS function libraries used by the DB application. I initially wanted to test just the ReadFile.js functions, but they turned out to be too interrelated to the functions in the Pfind.js file.

So, I built OnChng04.htm and also made a quick test database file called Tags.txt to see if the tags would load correctly and be link-able using both ReadFile.js and Pfind.js

After a few false starts and new bugs/problems introduced by the new code, I was able to prove (approximately 2 hours later) that the anchors were being loaded correctly. They could be found, that is, they could be picked up from the select box and used to build a new URL. For some reason, the URL did not move to the correct place in the file so I threw out the Tags.txt file and tested using the original DB file - caret.txt - and that worked correctly. The problem in the test set-up was now in the test (Tags.txt) file so I didn't bother testing with it any further. All of this points out an important point: when we start creating new test files we will inevitably create new bugs which may well hide the original problems and bugs. We must be very careful to remove all newly introduced bugs so that we are truly testing what we think we are testing.

I now knew two important things:
1. The <select> drop-down to new URL concept works in Netscape just fine.
2. None of the JavaScript functions created to implement this feature are the cause of the problem in the DB application. (Both the Pfind.js and ReadFile.js files and all their functions are fine as is.)

This meant that the problem must have been in the original HTML file, caret.htm.

To test this I could create a new test HTML file that has everything in it needed to implement the anchor search feature and add the other features one at a time till we break the test application. Or, I could create a test HTML file that has everything the original DB HTML file has in it and remove features one at a time till the anchor search feature starts working. This means I am assuming that either there is an interaction between features causing the problem or there is a bug that only shows up in Netscape causing Netscape to not correctly pick up the newly created <select> box object.

If we get down to just the anchor search feature and it still does not work, then we will need to debug just the one feature, i.e. there is no bug due to interactions between features.

I started with a minimal HTML file to implement just the anchor search starting with the code as it is in the DB application HTML file. I called this file: OnChng05.htm. Once I had this file working, I started over with OnChng05 by copying it to OnChng06.htm, then I started cutting and pasting lines, a few at a time, from caret.htm to OnChng06.htm and testing each change. I was rather lucky because as soon as I picked up the two-titles section of code, the program stopped working.

Here is the title HTML section. See if you can see anything wrong with it:
Code:

<center>
<font face="arial">
    <h2>
      <script language="JavaScript" type="text/javascript">
        document.write(TitleMsg);
      </script>
    </h2>
<h3>(A Pfind Application) CARET Version 2.30</h3>
<b>
</b>
</center>

I found the HTML problem right off but I didn't recognize that the undefined object problem had been fixed by my simple HTML change. I had changed the code to this:
Code:

<center>
<font face="arial">
    <h2>
      <script language="JavaScript" type="text/javascript">
        document.write(TitleMsg);
      </script>
    </h2>
<h3>(A Pfind Application) CARET Version 2.30</h3>
</font>
</center>

It turned out that by simply closing the open <font> tag, the problem was solved. It took me another day to confirm that with tests because I was sure that there had to have been a hidden character I had eliminated. I tested the hidden character theory twice by looking at that section of code with my TextPad editor. I saved the original section of code as code.txt and renamed it code.bin, then TextPad read it in as if it were a binary file so I could see everything in hex. I found no hidden characters so that's when I finally decided to test out removing the closing </font> tag again and, sure enough, Netscape once again claimed that the drop-down list object was undefined.

That's it. It took me about three days and eight hours of work to fix the problem and another hour or so to actually locate the real code problem, the missing closing </font> tag.

I've since found another bug that has crept in since the initial version. I find I can no longer load different databases on-the-fly - the DB always reverts to the initial database in the names[0] location, but that's another debugging task. Actually this was due to a debugging line I installed to force the loading of the same file no matter what. My fault. Another HINT: Remember to label all debugging lines in some way so you can find and remove them (or comment them out) before you test the final "working" code again. I had done this, so when I searched on my test label, pk01, I found the remaining debug line right away.

I hope this helps you to become better debuggers.
_________________
Phil K
Circle Software Consulting
Test website: http://cs.yrex.com/
Guidelines for Posting: http://jsworkshop.com/posting.html
IHBAAA = It Has Been Asked And Answered
KISS: http://jsworkshop.com/bb/viewtopic.php?t=508
Back to top
View user's profile Send private message Visit poster's website
JasonGawker
New member
New member


Joined: 13 Apr 2008
Posts: 1
Location: ASD

PostPosted: Sun Apr 13, 2008 1:44 pm    Post subject: Hi Reply with quote

Hello,

Yea, those techniques are highly useful. I've been a programmer for a few years, and started doing JAVA just recently. The debugging bit is essential for any software development, and the ones implemented in JAVA are extremely good. I recommend this book to anyone who's interested in learning JAVA and expanding his scope of interest into debugging as well.
Back to top
View user's profile Send private message
sohnee
Senior Member
Senior Member


Joined: 17 Jul 2002
Posts: 2054
Location: UK

PostPosted: Mon Apr 21, 2008 12:01 am    Post subject: Reply with quote

Debugging isn't required in all programming methodologies.

If you use an extreme programming methodology, debugging isn't part of that and the way your write code changes.

I just thought I'd mention that as debugging doesn't have to be ingrained in every piece of code you write.
_________________
I also work on... Steve Fenton's Blog and contribute to The Enhance PHP Unit Testing Framework
Back to top
View user's profile Send private message Visit poster's website
phil karras
Senior Member
Senior Member


Joined: 15 Jul 2002
Posts: 1750
Location: MD

PostPosted: Tue Nov 08, 2011 3:47 am    Post subject: Reply with quote

Shonee,

Debugging no matter what the paradigm is always going to be a requirement. This is because even if all other bugs can be eliminated the logic errors still remain because they were created by our own incorrectly thinking through the problem and we will still need to find those because in all other respects they are programmed correctly and the program is doing what we "thought" we wanted. So there is no way for a debugger, other than our own brains, to debug our own mistaken assumptions and the logic errors.
_________________
Phil K
Circle Software Consulting
Test website: http://cs.yrex.com/
Guidelines for Posting: http://jsworkshop.com/posting.html
IHBAAA = It Has Been Asked And Answered
KISS: http://jsworkshop.com/bb/viewtopic.php?t=508


Last edited by phil karras on Mon Nov 21, 2011 8:50 am; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    JSWorkshop Forum Index -> Articles All times are GMT - 7 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2002 phpBB Group
(c) 1997-2002 Starling Technologies and Michael Moncur. Portions (c) Sams Publishing.