Upload
others
View
8
Download
0
Embed Size (px)
Citation preview
Department of Computer Science School of Computing National University of Singapore
2007/2008
Debugging and Testing for a Browser‐based Application Platform Honours Year Project Report
Zhou Lin
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 2
Title Page
Honours Year Project Report
Debugging and Testing for a Browserbased Application Platform
BY ZHOU LIN
DEPARTMENT OF COMPUTER SCIENCE
SCHOOL OF COMPUTING
NATIONAL UNIVERSITY OF SINGAPORE
2007/2008
Project No: H041240
Advisor: Assoc Prof Martin Henz
Deliverables:
Report: 1 Volume
Program: 1 CD‐Rom
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 3
Abstract The emergence of the Internet increased the popularity of web-based applications.
Despite the server-side applications which usually have extensive development
support, the client-side applications, which largely based on the client’s web browsers,
lack a good debugging and testing support as server or desktop applications do. This
report explores the various possibilities of implementing debugging support and
security control for applications that based on web browsers as well as a systematic
way of testing them. A source transformation methodology is implemented to build
the features into the JavaScript program themselves. By using the intermediate JSON
format and XML format, the JavaScript program can be conveniently manipulated in
the browser. This report also recommended a testing framework for JavaScript
applications that separates test data from the programs.
Classifications:
D.3.4 Programming Languages Processors
D.3.1 Programming Languages Formal Definitions and Theory
D.2.5 Software Engineering Testing and Debugging
E.2 Data Storage Representations
Keywords:
JavaScript, JSON, Parser, Compiler, Source Transformation, Unit test, Debugger
Implementation Software:
Narcissus, Mozilla Firefox 2.0, Java 1.
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 4
Acknowledgement I wish to thank Assoc Professor Martin Henz, My advisor for giving me inspirations,
guidance and encouragement.
And people who render me support during the course of this project. Thank you!
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 5
Table of Contents
TITLE PAGE ...................................................................................................................................... 2
ABSTRACT ....................................................................................................................................... 3
ACKNOWLEDGEMENT ..................................................................................................................... 4
TABLE OF CONTENTS ....................................................................................................................... 5
1 INTRODUCTION ....................................................................................................................... 7
1.1 BACKGROUND OF RESEARCH .......................................................................................................... 7 1.2 MOTIVATION AND TARGET............................................................................................................. 8 1.3 ABOUT TIDDLYCARD ..................................................................................................................... 8
2 FINDINGS .............................................................................................................................. 10
2.1 JAVASCRIPT (ECMA SCRIPT) LANGUAGE ........................................................................................ 10 2.1.1 Weakly Typed Variables and Functions ............................................................................ 10 2.1.2 Tolerance of Undeclared Variables ................................................................................... 10 2.1.3 Lack of Control for Object and Function Access ................................................................ 10 2.1.4 Lack of Block Level Scoping ............................................................................................... 11 2.1.5 Interpretational Style Execution ....................................................................................... 11 2.1.6 Tolerance of Minor “Syntax Mistakes” ............................................................................. 11 2.1.7 Use of Expression as Statement ........................................................................................ 11
2.2 EXISTING UTILITIES FOR BROWSER‐BASED APPLICATIONS ................................................................... 12 2.2.1 Venkman/JavaScript Debugger (Mozilla/Netscape Add‐on) ............................................ 12 2.2.2 Firebug (Mozilla Firefox Add‐on) ...................................................................................... 13 2.2.3 Mozilla Error Console (Mozilla Built‐in) ............................................................................ 14 2.2.4 JSLint (Online, for All Browsers) ........................................................................................ 14 2.2.5 Scripting Debugging (IE Built‐in) ....................................................................................... 15 2.2.6 Internet Explorer Developer Toolbar (IE7 Add‐on) ............................................................ 16 2.2.7 Apple Safari Web Inspector (Safari Built‐in) ..................................................................... 16 2.2.8 Opera Error Console (Opera Built‐in) ................................................................................ 17 2.2.9 Opera Developer Console (Opera Add‐on) ........................................................................ 18 2.2.10 Aptana Studio (Application for Firefox and IE) ............................................................. 19
2.3 REMARKS ON THE FINDINGS ......................................................................................................... 19
3 DEBUGGING SUPPORT........................................................................................................... 21
3.1 ASSERTION ............................................................................................................................... 21 3.1.1 The Method ...................................................................................................................... 21 3.1.2 The Advantage .................................................................................................................. 22 3.1.3 The Limitation and Drawback ........................................................................................... 22
3.2 SOURCE LEVEL DEBUGGING ......................................................................................................... 22 3.2.1 Conversion Rules ............................................................................................................... 23 3.2.2 Sample Scenarios of Use ................................................................................................... 25 3.2.3 More Powerful Source Transformation ............................................................................ 28
4 TESTING SUPPORT ................................................................................................................. 30
4.1 TESTING MODEL ........................................................................................................................ 30 4.2 TEST DATA ............................................................................................................................... 30
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 6
5 IMPLEMENTATION ................................................................................................................ 32
5.1 ASSERTION AND SYSTEM LOG ....................................................................................................... 32 5.1.1 Assertion ........................................................................................................................... 32 5.1.2 System Log ........................................................................................................................ 33
5.2 JAVASCRIPT‐TO‐JSON CONVERSION .............................................................................................. 35 5.2.1 Java‐based ........................................................................................................................ 35 5.2.2 Narcissus (JavaScript)‐based............................................................................................. 36
5.3 INTEGRATION WITH TIDDLYCARD CONSOLE ..................................................................................... 37 5.4 UTILITIES BASED ON THE TRANSFORMATION .................................................................................... 39
5.4.1 Global Variable Scanner ................................................................................................... 40 5.4.2 Call Stack Trace ................................................................................................................. 41
5.5 “ECMA UNIT” TESTING FRAMEWORK ........................................................................................... 42
6 CONCLUSION ........................................................................................................................ 43
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 7
1 Introduction
1.1 Background of Research The Internet Era has brought about many changes in our daily lives. One of such is
the emergence of the online applications. Even typical desktop applications such as
word processing and spreadsheets are shifting to online. These applications are all
based on one platform, the web browser.
In the early days of World Wide Web, the web browsers are not so powerful. The
online applications were largely based on the server and the browsers were just used
to display web pages and perhaps, do some simple validations. However, technology
advancement of today’s web browser has made it possible for applications to base
more on the client’s browser rather than the server. New technology trends such as
AJAX and JSON-RPC etc. are all browser-based. Browser-based applications provide
the users with more vivid and real-time experience without the hassle of installation
and configuration.
Despite all the benefits, the major problem of these web-browser-based applications is
the difficulty in maintenance and security control. Desktop applications usually come
with a handy set of tools enabling easy debugging and testing support, while the
browser-based applications typically receive a very limited development support from
the browser platform they run. It is even more difficult to have the security in control
while maximizing the power of these applications.
The investigation sets in from a web-based application “TiddlyCard”. TiddlyCard is
the successor of the TiddlyWiki, which is a client-side blog style personal notebook1.
TiddlyCard intends to create a framework for peer-to-peer web-based computing2. It
contains a plugin system that allows applications to be developed for the framework.
The implementation of the methodology in this report is based on but not limited to
the TiddlyCard system. It can be easily adapted for other web-based applications.
Utilities based on the methodologies suggested in this report can be used for other
browser-based applications with very few modifications.
1 Wikipedia article on TiddlyWiki, http://en.wikipedia.org/wiki/Tiddlywiki 2 Martin Henz, 2008
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 8
1.2 Motivation and Target The nature of the TiddlyCard requires it to be adaptable across multiple platforms.
The role of a framework for other applications also requires it to be error tolerant and
tamper proofing. In fact, this is the requirement of most browser-based applications.
On the other hand, the language that TiddlyCard and most other browser-based
application use is JavaScript (or ECMAScript), a relatively weak language for
implementing applications. The lack of strong typing, variable and function scoping
control is a constant stumbling block for an elegant and safe application. Besides that,
different browsers have different rendering engines and document object models, this
placed browser-based application developers in a dilemma of limiting the
functionalities of the application or giving up user groups of certain browsers.
Although there are some tools available for debugging browser-based applications,
they are mostly based on one type of browsers. As they are mostly run-time based, it
is possible that they will distract the applications. For example, the famous JavaScript
debugger, Firebug prevents TiddlyCard from loading and must be disabled before
TiddlyCard is able to be used.
This report sets in to investigate and evaluate the various possibilities of rendering
debugging and testing support into TiddlyCard, a typical browser-based application.
The aim is to surpass the limit of JavaScript and build the debugging, testing, as well
as security functionalities into the JavaScript applications themselves, with the
maximum level of automation.
1.3 About TiddlyCard Although this project is not just for TiddlyCard only, it started in and developed with
TiddlyCard. It is still considered as part of the framework of TiddlyCard. Therefore
terminologies in TiddlyCard may appear frequently in this report. In this part of the
section, we will briefly introduce the important concepts in TiddlyCard.
NUS Professor Martin Henz Defines the TiddlyCard as follows:
TiddlyCard is a framework for peer‐to‐peer web‐based computing. It consists of a client‐side "operating system" that boots within a web‐browser, and an ultra‐thin server side that enables peer‐to‐peer computing. TiddlyCard leverages on JavaScript, AJAX, COMET, TiddlyWiki and concepts from HyperCard to bring an environment to
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 9
the web browser, in which users, developers and enterprises can breathe, live and thrive.
The TiddlyCard has a mini OS. It has Input/Output systems called io system and a
Unix-like console User Interface, which is called “Turtle”. The OS houses many
applications, both in GUI and console.
Figure 1 shows the TiddlyCard loaded in Firefox. The web page that is behind the
console is “tiddlywiki”, a GUI application of TiddlyCard. There are also two
applications: Calendar and Messenger. The black box is the console named Turtle.
Commands are typed through the Command Input box. A command for the console
can have compulsory or optional arguments. The path in the TiddlyCard is mapped to
local file system and the browser objects. “/local/root/” in TiddlyCard corresponds to
the root in local file system, that is “/” in Unix and “C:\” in Windows; “/local/home/”
in TiddlyCard is the directory where the TiddlyCard main file is; “/global/” refers to
the entire browser object, it contains the “document” and “window” object.
The appendix X contains two articles that have more detailed introductions of
TiddlyCard. Please refer to them for more details about TiddlyCard.
Messenger Application
TiddlyWiki Application
Calendar Application
Console Turtle
Command Input box
Figure 1: TiddlyCard Interface
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 10
2 Findings
2.1 JavaScript (ECMA Script) Language JavaScript is the most famous name in the client-side web-browser programming. It is
almost an equivalence of saying web-browser-based applications. JavaScript was
designed to allow non-professional programmers to easily work with them. In the
early days of JavaScript, it is designed mainly just to open some browser windows,
pop up dialogue boxes, and do some form validations. Although the JavaScript has
evolved since then and has become much more powerful and complex in structure,
certain legacy still remained as part of the language characteristics:
2.1.1 Weakly Typed Variables and Functions JavaScript does not have an explicit typing system although it knows how to treat
strings, numbers and objects differently. As a result, it will not specifically check for
typing consistency for variables and functions. It will only throw exceptions when it is
impossible for program to proceed given the current statement and the variable value.
2.1.2 Tolerance of Undeclared Variables Because JavaScript itself is weakly typed, the declaration of the variables is simply
adding a “var” in front of a series of variable names. Any valid variable name or
object member name that does not currently exist will be registered as a global
variable once it appears at the left hand side of an assignment statement. It can be
easy for programmers to introduce global variables subconsciously. For instance, in
Figure 2, if “var” is left out, the x will become a
global variable upon the first entry of the
function, recursive calls to test(x) will keep
updating x. In the end the program will print
out a series of 0s, which is the final value of x,
while the programmer would probably want a
series of number from 1 to n.
2.1.3 Lack of Control for Object and Function Access In JavaScript, all of the objects and functions are open for “public” access. Although
it is possible to hide the functions and objects by wrapping them in a function (See
Figure 3), which hides the object from the rest of programs, once you assign the
variable or function to some global variable, they will become visible and callable
from entire application. The same case is for the document and window object, there
function test(n){ var x = n-1; if (x == 0) return; test(x); print(x); }
Figure 2: Undeclared Variable
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 11
is no proper way to hide the elements and
functions under document and window objects
from certain part of programs.
2.1.4 Lack of Block Level Scoping Unlike C and Java, JavaScript treats statements
under if…else… and while, for, and do…while
etc. same level as the statement body. This makes block statements merely arrays of
statements rather than individual objects. In JavaScript, only functions have different
closure from the main statement body.
2.1.5 Interpretational Style Execution A conforming JavaScript engine executes the JavaScript by interpreting the source
code. Therefore the JavaScript embedded an “eval” function to allow on spot
interpretation of JavaScript code. This can be potentially a security threat. Due to
copyright issues, different browsers usually implement different JavaScript engines
and APIs, thus has different “interpretation” on the same JavaScript code. This makes
it even harder for programmers to write programs that work on all platforms.
2.1.6 Tolerance of Minor “Syntax Mistakes” Depending on the version of interpreter, JavaScript can be very tolerant of syntax
mistakes. A typical example of this would be the missing semicolon(“;”). A
JavaScript can run perfectly fine in a lot browsers even it does not have semicolon as
statement separator. However, the level of tolerance still depends on the browser. This
may be part of the reason that the program may be able to execute on some browsers
but fail on others.
2.1.7 Use of Expression as Statement Recall in standard programming languages like C or Java, a
statement can only be certain types of expressions. A
statement like “x+y;” will get rejected by the compiler.
However, any expression can be used under JavaScript as a
statement. Combining this with the point mentioned in 2.1.5,
we can discover something interesting. In Fig 4, we have
two statements, which are equivalent in Java and C. However, for JavaScript, since it
can accept some “missing semicolon” and all expressions as valid statement, the
var g; function wrapper() { var myvar; function myfun() { ... } g = myfun; } g(); //call myfun() myfun(); //fails Figure 3: Function within Function
return x+y;
return x+y;
Figure 4: Expression Statement
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 12
interpretation goes: “return; x+y;”. Of course, the “x+y” is never calculated since the
function has already returned with an empty value.
2.2 Existing Utilities for BrowserBased Applications There are quite a few commercial or free utilities for browser-based applications. In
this part of the report, we will examine a few popular tools that aid browser-based
application development. The strength and limitations are identified so as to find out
what is really missing in the debugging and testing support.
2.2.1 Venkman/JavaScript Debugger (Mozilla/Netscape Addon)
Figure 5: Venkman/Firefox JavaScript Debugger
The JavaScript Debugger with the code name “Venkman” is considered as the official
debugger for Mozilla’s series of browsers3. It basically supports the following
debugging features:
Setting of break points and view content of the variables, call stack at the
break.
Choice of making errors break points.
Standard debugging techniques like Stepping through.
JavaScript program profiler, formatting and coloring.
3 Mozilla Developer Center on Venkman, http://developer.mozilla.org/en/docs/Venkman
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 13
Overall, Venkman is a good JavaScript debugger, yet it works only for Mozilla series.
2.2.2 Firebug (Mozilla Firefox Addon)
Figure 6: Firebug for Firefox
Firebug is the most popular debugger for JavaScript as well as DOM and CSS on
Firefox. It designs to serve all purposes of debugging in a browser. It has the
following features:
Setting the break point to break when certain expression evaluates to true
Choice of making errors break points. (Firebug automatically pops up at errors)
Setting watch for variables at break point.
Inspecting the DOM visually. This is possibly the part that is incompatible
with applications like TiddlyCard.
Inspecting, disabling and enabling styles in CSS. This could be prone to
incompatibility issues as well.
Firebug is very well designed for general purpose Firefox-based web pages. However,
due to its sophisticated features, Firebug might be interfering with complex JavaScript
applications. Issued as a Firefox extension, it works only on Firefox.
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 14
2.2.3 Mozilla Error Console (Mozilla Builtin)
Figure 7: Mozilla Error Console
Mozilla’s built-in error console is available for all the Mozilla series’ browsers. It
provides simple and straight forward details of syntax errors and uncaught exceptions.
The line number of the error is displayed and if you click on the URL below the error
name, it will bring up a textbox containing the color-formatted code where the error
occurs. The error console is a reliable built-in function for finding bugs, yet is not that
powerful.
2.2.4 JSLint (Online, for All Browsers)
Figure 8: JSLint JavaScript Checker
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 15
JSLint positions itself as a JavaScript syntax checker and validator4. It is mainly to
ensure that the user complies with certain rules. The effort is made in order to move
JavaScript into a more proper language. The website provides a list of requirements
for a properly written JavaScript program. The website is available freely online and
supposed to be working with main stream browsers. It now also does checks for
JavaScript written for Yahoo! widgets and Windows Sidebar Gadgets. JSLint is still a
project under development.
2.2.5 Scripting Debugging (IE Builtin)
Figure 9: Internet Explorer Script Debugging
With the most broad user base currently in the market5, Microsoft’s Internet Explorer
should not be a miss. However, debugging a browser application for IE could be the
hardest of all. Microsoft did provide a utility called Script Debugging, which is
available through some configuration in “Internet Options”. 6If there is an error, an
error sign will be displayed at the left bottom corner of the browser. Double clicking
on it will bring up the IE dialogue with the details of the error. A very confusing
problem with this dialogue is that the URL of the error provided is just the main html
document displayed in the main window. This problem made the debugging feature
almost useless because one cannot figure out which file is that “Line” and “Char”
referring to, and the error message is not that informative.
4 What is JSLint, http://www.jslint.com/lint.html 5IE family (version 5 to 7) takes up about 54.4% market share of web browsers as at Feb 2008 http://www.w3schools.com/browsers/browsers_stats.asp 6 Scripting Debugging in Internet Explorer, http://blogs.msdn.com/ie/archive/2004/10/26/247912.aspx
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 16
2.2.6 Internet Explorer Developer Toolbar (IE7 Addon)
Figure 10: Internet Explorer Developer Toolbar
Starting from version 7.0, Internet Explorer supports add-ons that are similar to that of
the Firefox’. The IE Developer Toolbar is developed by Microsoft to enable
inspection of DOM and CSS of an html document. It can be considered as the
CSS/HTML/DOM subset of the Firebug in Firefox. It does not really deal much with
JavaScript. It serves more as an inspector of webpage structures.
2.2.7 Apple Safari Web Inspector (Safari Builtin)
Figure 11: Safari Web Inspector
Available from Safari version 3.1, Apple’s Web Inspector is from the Develop menu
which is available if the “Show Develop Menu” option in the Preferences is enabled.
Similar to the Error Console in Firefox, when an error or uncaught exception occurs,
the Web Inspector’s Error Console displays the error message together with the script
file name and the line number where the error occurs. Clicking on the error will bring
you to the line in the script file. On the left hand side panel, the web inspector lists the
files used by the current page. Select these files and the source will be displayed in the
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 17
right hand side panel. Safari’s support for debugging as a browser is considered
comprehensive. Yet many times that piece of information may not be sufficient for
debugging.
2.2.8 Opera Error Console (Opera Builtin)
Figure 12: Opera Error Console
As a small browser, Opera’s error console is the most comprehensive of all the
previous browsers that we have seen (Mozilla, IE and Safari). It does not only print
out the error type and the line number, but displays a back trace of exception with line
number as well. The error console also deals with XML, HTML, CSS and many other
types of errors.
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 18
2.2.9 Opera Developer Console (Opera Addon)
Figure 13 Opera Developer Console
The Opera Developer Console is a new add-on to the new versions of Opera7. It
provides even more in-depth support on Opera. Users can view the current page from
the point of a document (DOM view), or JavaScript objects (JS view). There are CSS
view and network request view as well. In the JS view, the list of user created and
browser objects (variables, functions and objects) and their respective value will be
displayed. User can choose to display only the user-created objects. From a browser-
based application developer’s point of view, this developer console can be seen as a
variable and function watcher and a DOM inspector.
7 New weekly build http://my.opera.com/desktopteam/blog/2007/02/02/new‐weekly‐build
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 19
2.2.10 Aptana Studio (Application for Firefox and IE)
Figure 14 Aptana Studio
The Eclipse-based application Aptana has a Java-like IDE interface. On the left hand
side there are file browsers and project management tools and on the right hand side
there is the list of functions. It is supposed to have integrated JavaScript debugging.
Yet for the tests ran on the IDE, the console just seems to reproduce the error console
in firefox, just that it is without the detailed file and location information. The
information is thus not that helpful. An attempt to create a break point in Aptana
seemed failed to work in Browser. Aptana serves as a good JavaScript coding
environment, however its debugging power for browsers scripts is quite limited.
Aptana places its focus on Ajax web applications. It seems to have more to do with
the company’s own Ajax server called Jaxer. The debugging component in Aptana
makes more sense when it comes to the server part of Ajax which is on Jaxer.
2.3 Remarks on the Findings While there are more JavaScript utilities, these ones presented here are popular and
representative. In fact, lots of the utilities that we review in this section are champions
in their own realm, like Firebug for Firefox, Venkman for Mozilla and the Developer
Console for Opera. There are also utilities checks for standards compliance and that
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 20
inspects DOM. These utilities ease the life of web programmers a lot. However, just
like the first part of this section mentioned, JavaScript language is interpreted thus
different interpretation is possible on different platforms. A web programmer usually
has to test and debug his programs on multiple platforms before he is able to publish
his program. It is still a common phenomenon that some websites or applications only
support a certain kind of browser.
The increasing diversity of browsers (and some are without good debugging software
like Firebug) makes the life of web programmers even harder. While there seem to be
no single debugger that works for all JavaScript on all platforms, we wonder what if a
JavaScript program can debug and test itself. With the self debugging and testing
facility, the JavaScript can be debugged everywhere and tested on every platform
without getting a tool that is specific to that platform. Debugging and testing within
JavaScript itself, this is where this project sets off.
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 21
3 Debugging Support In this section, we’ll be examining ways to embed debugging within JavaScript itself.
The first method looks from the dynamic debugging which includes manual insertion
of certain codes in the JavaScript program. The second method uses source
transformation, which allows the original JavaScript program to be free from any
extra codes and easier to put into deployment.
3.1 Assertion
3.1.1 The Method This version of debugging/testing support works like the assert() statement in most
languages. It serves as a predicate for the script to continue. Programmers can insert
the assert statement in any part of the code. Assertion failure messages will be
displayed if the predicate is not evaluated to true. A state variable called debug mode
is kept so that by setting the debug mode, users can decide how and whether to
display the assertion failure. When the system is going to deployment, the debug
mode can be set to “NO_DEBUG” or 0; in this case the asserting predicate will not
even be evaluated. The implementation chapter contains the detailed description of
the debug modes and how each command works.
mode can be set to “NO_DEBUG” or 0; in this case the asserting predicate will not
even be evaluated. The implementation chapter contains the detailed description of
the debug modes and how each command works.
Figure 15 contains a brief diagram showing how this assertion system is designed:
Figure 15 contains a brief diagram showing how this assertion system is designed:
Debug Mode Setter
JavaScript Source: tc.debug.setDebugMode(DEBUG_CONSOLE); …………………………………….. …………………………………….. …………………………………….. tc.debug.assertion(“a>b”, “a should be > b!”); ……………………………………. ……………………………………. ……………………………………. tc.debug.assert.isEqual(result, 7, "tc.debug.Add failed"); ……………………………………. ……………………………………. ……………………………………. tc.debug.setDebugMode(NO_DEBUG); ……………………………………. …………………………………….
Assertion Processor
Debug mode
User Output
Assert Log
Figure 15 Assertion Work Flow
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 22
The assertion log is stored so that user can view it later. If we set the debug mode to
not display the failure on the spot but store it in the log only, this system becomes an
unit testing environment where the test cases are embed in the assertions.
3.1.2 The Advantage This system is easy to implement and works on most browsers since there is no
complex data structure or program structure involved.
Besides that, the system can combine achieve multiple purposes including asserting
debugging and unit testing.
Lastly, it is more elegant than the “alert box” debugging8 and it is not necessary to
remove all the debugging statements for deployment.
3.1.3 The Limitation and Drawback This system relies on the programmer to codes all the assertions; it still requires the
extra effort.
Secondly, when the debug mode is set to NO_DEBUG for deployment, although the
assertion calls will be returned straight away, there is still a bit of overhead trying to
call the function and rebuild the call stack.
Moreover, in terms of debugging support, the system is merely a more elegant version
of “alert box” debugging. It does not provide a stack trace or anything that could be of
assistance to identify the errors.
Lastly, there is no way to deal with the security issues. We cannot find
Although many attempts have been done, this seems to be the best results we can
accomplish by dynamic debugging given the current language features in JavaScript.
In order to make JavaScript really capable of debugging itself, we must to proceed to
the next level, which is at source level.
3.2 Source Level Debugging Source level debugging, as the name suggests, deals with JavaScripts in their source
form. This is not possible without a proper lexer and parser. While a good parser is
not available in JavaScript, we looked at the alternative of borrowing the power from
8Debugging JavaScript programs http://www.javaworld.com/javaworld/jw‐07‐1996/jw‐07‐javascript.html
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 23
a more powerful language, Java. In this way, we can focus on the source level
debugging rather than writing a parser in JavaScript. However, in order to limit the
reliance on Java, it is decided that the process will be divided into three stages, show
in Figure 16 below:
In this process, JSON (JavaScript Object Notation) is chosen as the intermediate
format. JSON is a JavaScript based data exchange format9.
In the first stage, the JavaScript source is converted into JSON format using a parser
plus a JS2JSON converter written in Java. This parser and converter are later replaced
by a JavaScript version.
In the second stage, with the parsed JSON representation of JavaScript Source, we
can perform the desired code transformation (insertion, deletion and modification)
using JavaScript, since JSON can be parsed into JavaScript easily as a native
JavaScript object.
In the last stage, the transformed JSON will be converted back to JavaScript and is
now executable under any browser.
3.2.1 Conversion Rules A set of conversion rules is designed to map JavaScript into JSON. The set of
conversion rules has the following characteristics:
9 Introducing JSON, http://www.json.org/
Figure 16 Three Stage Process of JavaScript Transformation
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 24
• Every element in the JavaScript language has a corresponding representation
in JSON
• Given any JavaScript program, reverse conversion is able to produce a
syntactically identical JavaScript from the JSON representation of the original
JavaScript.
• Non-syntactic features like spaces, tabs, and comments will not be preserved.
• New language element can be easily introduced into the system.
Based on the above guidelines, each JavaScript element will be represented as a
JavaScript object with the following object member:
• “type”: specifies the type of the element, can be either “Script” (JavaScript
Program), “function”, “statement” or “expression”.
• “subtype”: specifies the actual type for the statement or expression. For those
elements that has type = function or Script, they do not have a subtype.
• The rest of the object member depends on the “type” and “subtype”.
For example, given the following expression: a=b*(++c), the corresponding JSON
representation is:
{"type":"expression", "subtype":"assignment rator":"=", ", "ope"left":{"type":"expression", "subtype":"identifier",
"identifier":"a"}, "right": { "type":"expression", "subtype":"operator","operator":"*",
"left":{"type":"expression", "subtype":"identifier", "identifier":"b"},
"right":{"type":"expression", "subtype":"unary", "prefix":"++", "expression":{"type":"expression",
"subtype":"identifier", "identifier":"c"} }//end of (++C)
}//end of (b*++c) }//end of (a= b*++C)
For a “while” statement (while (a) {}), the JSON representation is:
{"type":"statement", "subtype":"while", "condition":{"type":"expression", subtype":"identifier",
"identifier":"a"}, "loopbody":{"type":"statement", "subtype":"block", "body":[]}}
For a function such as function f(a, b){}, the JSON representation is:
{"type":"function", "name":"f", "parameters":["a","b"], "body":[]}
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 25
For a JavaScript with empty body, the JSON representation is:
{"type":"Script", "content":[]}
A full conversion table can be referenced in the appendix.
3.2.2 Sample Scenarios of Use Here we present several sample scenarios of using source transformation.
1. Coding Standards Checking/Verifying:
Besides the syntax correctness which can be ensured by the parser, this coding
standards checker will perform the check for a standard beyond the
requirement of JavaScript. The standard is customizable to meet different
requirement.
For example, the TiddlyCard requires no global variables to pollute the global
name spaces while it is easy to introduce global variables accidentally in
JavaScript. Global variables in JavaScript can be introduced by declaring at
root level or assigning a value to an undeclared variable at any level, As
shown in the code fragment below:
Based on the converted JSON representation of the JavaScript program, it is
possible to track down where these variables are introduced and help the
programmer to correct the mistakes.
2. Implementing a call stack
//JavaScript var a=0, b; function f(x) { var c=10; d=c+1; function f2(y) { e=y+3; return e; } return n; } if (a==0) { var m=1; }
a, b: declared global variables f: global function variable (c is declared in f, not global) d: undeclared global variable (f2 is within f, not global) e: undeclared global variable (n is not global but an error will be thrown since no is undeclared) m: declared global variables
Figure 17 JavaScript Global Variables
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 26
When Java program throws an exception, the exception will contain the
detailed trace of call stack. However, for JavaScript, most of the browser built-
in error console only provides a line of information about where the error
occurs. However, this information is meaningless if recursion and multiple
function calls are involved. Under the current model of JSON representation,
it is not difficult to transform a JavaScript program such that the call stack can
be kept and printed when an error occurs.
Figure 18 shows a pseudo-implementation of the call stack as implemented
with the source transformation model. The inserted codes are italic.
3. Dealing with timeouts in unit testing.
In unit tests, we need to make sure a program either succeeds or fails but are
not looping forever, However, there is no way for a JavaScript function to stop
another function from executing. Some browsers will pop up a dialogue box to
prompt the user whether or not to stop the script if the script has been running
for too long. However, these browsers will kill all the scripts, not just the error
ones. With JavaScript encoded in JSON representation, we could easily write
a program to insert a check at every function call and every loop structure to
check if the program has exceeded its time limit. This method allows the
program to proceed with the rest of the unit tests even one of the test cases has
Figure 18 Source Transformation for Call Stack Implementation
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 27
an infinite loop.
As shown in Figure 19, after the program is transformed, it has the ability to
detect a time out and then throw an exception to stop the infinitely looping
script. The host script (in this case, the unit tester) will be able to receive the
exception and show a “Timeout” status for the test case.
4. Replacing unsafe expressions (expression mapping)
The DOM and the window object are not protected in JavaScript. Any
JavaScript once introduced can call them to display dialogue boxes, alter the
DOM content and do many other things. Though we could overwrite them by
redefining the respective functions (such as window.alert =
function(n){…}), it will deny access from programs that we want it to work
as well. Again in the form of JSON representation, these calls can be replaced
by safer alternatives. In another word, we could force these programs not to
call the system directly but instead call the safer alternatives.
Figure 20 below shows the source function f on the left is applied
transformation with the listed expression mapping rules and then become the
target function f on the right.
function f() { if (checkTimeOut()) throw “Time Out”; //for every function entry, check time for(var i=0; true; i++) { if (checkTimeOut()) throw “Time Out”; //for every entry into loops, check time } while (a < b) { if (checkTimeOut()) throw “Time Out”; //for every entry into loops, check time } } function checkTimeOut() { return (Date().getTime() - _startTime > TIMEOUT); }
Figure 19: Source Transformation Prevention of Infinite Loops
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 28
3.2.3 More Powerful Source Transformation The example scenarios presented in the previous section all require the programmer to
write specific transformation rules in JavaScript. In this section we are going to
discuss a systematic way of describing transformation requirements. Two different
approaches were evaluated:
3.2.3.1 JSON Transformation (JSONT) JSONT is native JavaScript or rather JSON based. The author of JSONT aims to
create a XSLT-like transformation language for JSON10.
There are two types of JSONT rules:
"name": "transformation string"
"name": function (arg) { … }
The “name” is referring to the name in the name and value pair of JavaScript objects.
In the first type of rules, user can embed “{expr}” tags in which {expr} refers to the
name of another member of the object. In the second type of rules, a function is
supplied to process the value of the object member, and return a processed string.
However, during implementation of this method, it is discovered that the method does
not have a good support on the path, that is, the method’s path can only refer to the
root level, while the JSON representation of JavaScript contains arbitrary number of
levels. Furthermore, because the notation that are used to identify JavaScript language
elements depends on “type” and “subtype”, these still have to be written as JavaScript 10 Transforming JSON, http://goessner.net/articles/jsont/
Figure 20 Source Transformation Replacing Unsafe Expressions (Expression Mapping)
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 29
functions within the transformation object. It is not efficient nor makes the code more
tion. readable to use this nota
3.2.3.2 XML and XSLT Being another data exchange format, XML is more developed and accepted in more
places, although it might be a bit heavy-weight for JavaScript. The reason why XML
is considered is because of the transformation language XSLT. XML and XSLT
combination is accepted by most browsers, and XSLT is a more developed
transformational language.
The XSLT support is built into the JavaScript transformation package. Users of the
package may specify transformation rules in XSLT. The transformation package will
convert the JSON (JavaScript Object) into XML DOM object. Transforming the XML
DOM with the XSLT is implemented through the native functionality of the web
browser.
The transformation process can now be illustrated as follows (Figure 21):
Figure 21: Source Transformation with XSLT
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 30
4 Testing Support As browser-based applications grow, the size and complexity of the applications also
grow. Statistics show that software errors cost about 60 billion US dollars yearly in
the United States11. Testing is an important way to avoid bugs. Browser-based
applications lack a standard way of testing them. This part of the report suggests a
systematic way to test the browser-based applications
4.1 Testing Model This testing method is based on the following model:
1. The browser-based application is JavaScript based, or this method will test
only the JavaScript component of the application. The justification for this is:
o HTML (purely browser content) is not an application but rather form
layout. It can be handled by html editors.
o Those applications based on plugin technologies embedded in
browsers, such as Java and ActiveX, are not really browser-based and
usually has already a good testing and debugging environment.
ActiveX is even platform dependant.
2. The test will be carried out as executing a JavaScript function using a pre-
determined input and comparing the output with the expected values. The
expected value can also accept a function to help determine whether a result is
correct.
This testing model is similar to most other unit testing tools. The major use of this
testing is to assure the correctness of the functions in JavaScript.
4.2 Test Data In order to separate test data with the programs and improve JavaScript standard
compliance, the test data are to be written in a JSON file.
The test data file contains the meta information such as the author of the test case.
Users can also specify a timeout attribute so that when a test case executed beyond the
limited timeout, it will be interrupted get a Timeout as the result. It also needs a list of
11 Software errors cost U.S. economy $59.5 billion annually, http://www.nist.gov/public_affairs/releases/n02‐10.htm
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 31
Figure 22 Sample Test Cases Data
files (resources) to be loaded into the system in order to start the test. The files can be
specified as absolute or relative paths. It is suggested that the test case should be
stored as a .testdata at the same directory with the rest of the JavaScript programs
being tested, as the test data will be more portable.
The most important part of the test data file is the test cases. The test cases are to be
organized by the function to be tested. Within each function to be tested, there are test
cases which consist of an input and an expected output. The expected output can be
string, number, object, or any type that is comparable in JavaScript. Instead of an
expected output, user can provide a function (that returns either true or false) to verify
if the output is correct.
Below is an example of test data:
The input (argument) to each test case must be a valid expression wrapped with
quotes. This ensures these expressions are not evaluated until the test case runs.
var testdata = { “author”: “Zhou Lin”, “timeout”: 500, //time limit for each case in ms “resources”: [ “arithmetic.js”, “problem.js”, “xml.js” ], “tests”: [ { “function”: “tc.math.add” “cases”: [ { “input”: “2, 3”, //2 arguments “expect”: 5 }, //numeric outcome { “input”: “-5, -7”, //2 arguments “expect”: -12 } ] //numeric outcome }, { “function”: “tc.math.sqrt” “cases”: [ {“input”: “100”, “expect”: “10”},//1 argument {“input”: “24”, //1 argument “evaluator”: function(x){ return (x<5 && x>4);} } ]//customize evaluator }] };
Meta data
Resource List (Files to be loaded)
Test Cases
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 32
5 Implementation The package submitted with this report includes an implementation of the debugging
and testing tools that we have discussed in the previous chapters. The implementation
is based on the TiddlyCard system but can be easily plugged into other systems. For
the source transformation part, the utilities can be directly used for other browser-
based applications on the local storage.
5.1 Assertion and System Log Assertions and system logs were part of the earliest attempt in the timeline of the
project. They have become part of the core system in TiddlyCard. The source
program for this part can be found in src/tc/debug/.
5.1.1 Assertion Based on the features provided by TiddlyCard, users can choose from the following
modes of assertion:
• tc.debug.NO_DEBUG (0): Nothing will be done. The values are not even
evaluated.
• tc.debug.DEBUG_ALERT (1): An alert dialogue box will be pop up to show
the assertion if the assertion fails. This mode is suitable if not many assertion
failures are expected, because each failure will pop up a message box and
require the user to press “OK”.
Figure 23: Assertion Message ‐ DEBUG_ALERT
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 33
• tc.debug.DEBUG_CONSOLE (2): The assertion messages will be printed on
the console directly as the program runs.
Figure 24: Assertion Message ‐ DEBUG_CONSOLE
• tc.debug.DEBUG_LOG (3): The assertion messages will only be recorded in
assertion log (system variable) and nothing will be displayed. User can read
the stored message by entering “lslog” command. Note that even under the
ALERT and CONSOLE mode, the log will still be kept. Use “clrlog” to clear
the log.
Figure 25: Assertion Message ‐ DEBUG_LOG and Operation on the Log
The related program can be found in src/tc/debug/test.js. A demonstration of usage
can be found in src/tc/debug/demotest.js.
5.1.2 System Log The system log for TiddlyCard aims to keep a runtime record of the TiddlyCard.
Programs can call the system log to record events. Events are recorded according to
its subsystem, and the type of message.
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 34
There are four types of message:
• tc.debug.log.LEVEL_DEBUG (1) Debugging message
• tc.debug.log.LEVEL_INFO (2) Information message
• tc.debug.log.LEVEL_WARN (4) Warning message
• tc.debug.log.LEVEL_ERROR (8) Error message
The system can be configured (by using tc.debug.log.setLevel function) to listen to a
combination of types of messages. For example, if the system is set to record at level
10, that means it will listen to Info and Error messages (2+8).
When sending a log message to the system, the program needs to specify its
subsystem name, type of the message and the log message. The system will record the
message separately for each subsystem and date and time when the system receives
the message will be recorded.
When TiddlyCard system exits, these logs, if any, will be stored inside TiddlyCard
directory “log” under the name of “tclog” following the exiting date and time.
The related program is src/tc/debug/log.js. A demonstration of usage can be found in
src/tc/debug/logdemo.js.
Log level set to:
LEVEL_ALL (15)
Log level set to:
LEVEL_WARN (4)
Figure 26: System Log
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 35
5.2 JavaScripttoJSON Conversion Source transformation plays crucial role in this project, while the JavaScript-to-JSON
conversion is the essence of this source transformation. In the beginning, there was no
proper parser for JavaScript that can be directly run on the browser. Therefore, the
project started with writing a parser and converter in Java.
5.2.1 Javabased At first a LL(n) parser generator, JavaCC was chosen as the parser generator.
However, the writing of LL(n) grammar for JavaScript was found to be unsuccessful,
majorly because of the specialty of JavaScript’s language structure. Although there
are some online resources claiming to have written a LL(n) grammar for JavaScript,
these resources turned out to have missed some language elements as specified in the
ECMA-262, 3rd Edition. In the end, we have to abandon writing the LL(n) grammar
for JavaScript.
The project is then switched to the LALR grammar, jFlex+JavaCup. This effort
finally turned out to be a success. A JavaScript to JSON converter was born. The
converter takes in a JavaScript file and converts it to a JSON file with the same file
name. The JSON file can then be read and manipulated under JavaScript environment.
The following picture shows the converter’s running process (bottom) and output
(right hand side).
Figure 27: JavaScript to JSON Converter using Java
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 36
5.2.2 Narcissus (JavaScript)based During one of the regular discussions, a TiddlyCard developer introduces two
interesting JavaScript application, JSLint and Narcissus. The JSLint was mentioned in
Section 2 of this report. It is an online JavaScript code verifier written in JavaScript
which uses its proprietary parsing scripts. However, when JSLint was tested, it turned
out most programs were rejected by JSLint and not even getting parsed (that was in
November, JSLint seems to be able to parse more programs when it was tested again
most recently). It seemed that the JSLint’s parser only accept “a stricter subset of
JavaScript”12. This obviously does not meet the requirement.
Narcissus is a JavaScript interpreter implemented in JavaScript. It can be found in
Mozilla’s development CVS branch. Unlike the strict JSLint, Narcissus is more
general, any way it is written by the same author who has also written the JavaScript
engine for Mozilla browsers. The first problem we had while using Narcissus is that it
cannot work on any browsers, not even on the latest Mozilla browser. Wikipedia
mentioned that the author has used a lot of features that are only available for a
development branch of Spidermonkey (the code name for JavaScript engine in
Mozilla series’ browsers). To use Narcissus as suggested by Wikipedia, the only way
is to check out from CVS and build the Spidermonkey engine and compile it with
“NARCISSUS=1”.13 There is no advantage as compared to Perl if the JavaScript has
to be used in this way.
Nevertheless, after studying the code of Narcissus, we discovered that a lot of codes
that are not compatible with Firefox browser are to deal with the execution of the
JavaScript. Plus some of the features which are not supposed to be in the browser are
actually supported by the new versions of the Mozilla series browser. We only need to
deal with a few incompatible operations that are still remaining. Trial and error
method did work out in this project. Finally this is solved by a compatibility pack
JavaScript. All one need to do is to load this compatibility.js on Firefox first and after
which Narcissus JavaScript parser will run smoothly. This is tested on Safari and
Opera and they both worked. Unfortunately, the compatibility pack did not work out
on Internet Explorer. For some reason IE does not handle JavaScript arrays correctly.
12 JSLint Pratt Parser, http://www.jslint.com/lint.html 13 Narcissus, How to run, http://en.wikipedia.org/wiki/Narcissus_%28JavaScript_engine%29#How_to_run
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 37
However, this will not hurt the usability of the converter, because the output of the
converter can still be read in the Internet Explorer, and you could always use the Java-
based converter.
Until this point, the JavaScript transformation process is totally shifted into the
browser environment. The related files for JavaScript-based versions is contained
inside src/tc/app/jstransform. The JavaScript program that deals with JS-to-JSON
conversion is js2json_converter.js. An independent version (as compared to the
version merged with TiddlyCard, which will later be mentioned) is implemented in
js2json.html to provide a visual view for the transformation.
Figure 28: JavaScript Transformer Standalone Version in Safari
5.3 Integration with TiddlyCard Console JavaScript Transformer became more powerful after its integration with the
TiddlyCard system. It can now directly manipulate the files on the local disk, of
course, with the permission of the user. Unfortunately due to the stringent security
settings on Safari and Opera, TiddlyCard is unable to find many files on the local hard
disk and neither can JavaScript Transformer. It is only on the Firefox/Mozilla that you
can directly manipulate with the files on your disk.
The tools provided in this version are:
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 38
• JavaScript-to-JSON converter js2json [-o <output file>][-d <directory>][-s][-l] <input files> Convert a Javascript file into its corresponding JSON representation:
-o <output file>: output JSON file.
-d <directory>: common directory of input and output files.
-s: silent mode.
-l: keep extra line number information in the JSON representation. This is
required by applications like checkglobal (checkglobal need to print out the
line number of global variables).
<input files> filenames of JavaScript input files.
• JSON-to-JavaScript converter json2js [-o <output file>][-d <directory>][-s][-r] <input files> Convert a JSON encoded JavaScript back to normal JavaScript:
-o <output file>: output JavaScript file.
-d <directory> common directory of input and output files
-s: silent mode.
-r: execute the translated JavaScript once done.
<input files>: filenames of JSON input files.
• JSON-to-XML converter json2xml [-o <output file>][-d directory][-s] <input files>
Transform a JSON encoded JavaScript to XML.
-o <output file>: output XML file.
-d <directory>: common directory of input and output files.
-s: silent mode.
<input files>: are filenames of JSON input files.
• JavaScript Transformer with XSLT applytransform [-o <output>][-d <directory>][-s][-f <output
format>] -t <transformation-rule file> <input files>
Apply the transformation-rule file (encoded in XSLT) to a
JavaScript/JSON/XML encoded JavaScript, the file type is determined by its
extension. If the type of the input is not determinable from its extension, it will
be treated as a JavaScript source file.
-o <output file>: output JavaScript file.
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 39
-d <directory>: common directory of input and output files.
-s: silent mode.
-f <output format>: specify the final output format. Can be xml, json or js.
-t <transformation-rule file>: transformation rule in XSLT (compulsory).
<input files>: filenames of input files.
While using these commands, please take note of the following:
1. Because the TiddlyCard system currently does not support the query of
present working directory, the list-of-input files has to have a full path (i.e.
from /local/home or /local/root). Use the “-d” option if the input files are in the
same directory. Whatever directory you put after “-d” will be concatenated
with the input files you specified (so you can use relative path in input files).
Important: In order to provide convenience to users, the transformation
programs will try to look for the present working directory if a input file with
non-absolute path is entered and if “-d” option is absent. This will only work
for your first console window in a TiddlyCard session. It is strongly
recommended that you using “-d” option to ensure maximum workability.
2. The “-s” silent option will mute the normal output of the programs, in case of
an error or exception, the program will still print error messages.
3. If the output is not specified, the output file will have the same file name with
the file extension changed to the new format’s default extension. For example,
“json2xml /local/home/test.json” will give you a XML file called
“/local/home/test.xml”. If a relative path is specified in the output file, the
output path will be prefixed with the directory of the input file.
4. The input-file-list can have more than one file and they will be processed
sequentially. Note that you can only specify one “–o” output file. If you
supplied one output file and many input files, only the first input file will have
its output written to that output file. The result of the input files will have the
output files that are same name but different extensions from the input files.
5.4 Utilities Based on the Transformation The following utilities are implemented for the purpose of demonstrating the possible
usage of the transformation framework.
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 40
5.4.1 Global Variable Scanner This global variable checker will check in the JavaScript program and find out all the
global variables, including:
• Root level variables declared with “var” (label: GLOBAL),
• Root level function declaration (label: FUNCTON),
• Undeclared variables throughout the program (label: UNDECLARED). Recall
section 2.1.2.
The variables are detected and printed out, together with its line number in which it is
introduced and the type of the global variables. Usually it is the last type of variables
that a programmer is looking for.
To use this checker in the stand-alone version, just open the js2json.html and after
converting it to JSON.
Figure 29: Result of Global Variable Scanning
To use this checker under TiddlyCard, use the following command in the console: checkglobal –i <ignore-list> <JavaScript/JSON file name>
Figure 30: Result of Global Variable Scanning in TiddlyCard Console
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 41
The variables that’s in the ignore-list will be ignored during the scan. Use parenthesis
to group multiple global variables, e.g., “checkglobal -i ( tc window )
testvar.js”. Note that if a JSON file is specified, please make sure that it has line
number information attached (use “js2json -l” in console and check the “keep line
number” option in the standard version).
5.4.2 Call Stack Trace This call stack trace implements the model mentioned in section 3.2.2, scenario 2. To
use the call stack trace, the first step is to enable the JavaScript program with call
stack tracing ability. Under TiddlyCard console, use the following command: jstrace [-c <command to run>] [-d <directory>] [-s] [-v <stack
variable> <input files>
This command will create a new file whose name is the original file name plus a
“.trace”. The newly created file is an executable normal JavaScript. After executing
this command, these .trace files will be loaded automatically. Use “-c” option to
specify a statement to be executed after all the .trace files are loaded. By default the
variable used to store the stack is “tc.app.jstransform.callstack.__jst_callstack”. Use “-
v” to specify a new variable name for the stack variable.
After the .trace files are loaded, every statement that is executed afterwards
concerning these files will have the stack tracing abilities. The below shows an
example of Stack Trace:
Implementing Stack Trace
Executing Script
Listing Stack Trace
Getting Stack Detail
Figure 31: Stack Trace
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 42
Note that the stack will not be cleared until you enter the command “stclear”. Do
remember to clear the stack before you start the next command.
Commands used in Stack Trace:
• stprint
Prints out the stack trace of the last program failure, with brief information for
simplified viewing.
• stdetail <Stack Index>
Prints out the detailed content of the stack at the given index.
• stclear <Stack Variable>
Clear the stack trace (and set the stack variable).
5.5 “ECMA Unit” Testing Framework ECMA Unit testing framework is the implementation of the unit test framework as
file is stored inside
e .testdata file and then load it. Clicking on the “Run
test” will perform the unit test, as shown in the Screen below:
described in Section 4.
The test cases are based on the jstransform package. The .testdata
the jstransform package. Select th
Figure 32: ECMA Unit Testing
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 43
6 Conclusion This project began with the study of the characteristics of the most-used language in
browser-based applications, JavaScript. Being convenient and easy to get hands on,
the JavaScript has many compromises on the area of security, debugging and testing.
Although there are some software utilities and browser plug-ins that offers
programmers assistance, the assistance that they offer is limited to the platform that
they were based on. The variety of browser platform largely reduces the power of
these utilities and plug-ins.
At the early stage of the project, the attempt on run-time debugging techniques
achieved little. The hope lay on the source transformation of the JavaScript. The
inspiring idea was in the beginning very much challenged by the parsing of JavaScript
until Narcissus, the JavaScript based JavaScript engine was made working on the
browser environment.
The transformation is done by first parse a file into JSON, a
JavaScript based data exchange format. The JSON file can then be manipulated
ity.
oncatenated.
e
er platform they are used in.
nd convert the source
directly by JavaScript, or be further converted into XML and transformed by XSLT.
Depends on the purpose of the user, this transformation process can enhance, reduce
or optimize the JavaScript. After the transformation, the XML or JSON file can be
converted back to JavaSript and plug into any browser as a normal script.
ECMA Unit, a unit testing strategy is also designed and implemented in this project.
The strategy separates test data and test programs and allows the maximum flexibil
The final test result can be c
This project focuses on bringing debugging, testing and security features into th
language JavaScript, through the mean of source transformation. The transformed
JavaScripts can have self-contained debugging or security features that are
automatically built-in. These features can be carried along with the program
regardless of the brows
Debugging and Testing for a Browser‐based Application Platform (HYP H041240) Page 44
Appendix I: JavaScript-to-JSON Conversion Table