Debugging and Testing for a Browser-based …henz/students/richard.pdfDebugging and Testing for a...

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


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.


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!


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


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


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

http://en.wikipedia.org/wiki/Tiddlywiki


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


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


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


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


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

http://developer.mozilla.org/en/docs/Venkman


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.


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


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

http://www.jslint.com/lint.html

http://www.w3schools.com/browsers/browsers_stats.asp

http://blogs.msdn.com/ie/archive/2004/10/26/247912.aspx


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


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.


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

http://my.opera.com/desktopteam/blog/2007/02/02/new-weekly-build


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


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.


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


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

http://www.javaworld.com/javaworld/jw-07-1996/jw-07-javascript.html

http://www.javaworld.com/javaworld/jw-07-1996/jw-07-javascript.html


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

http://www.json.org/


• 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":[]}


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


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


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


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)

http://goessner.net/articles/jsont/


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


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


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


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


• 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.


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


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


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

http://www.jslint.com/lint.html

http://en.wikipedia.org/wiki/Narcissus_%28JavaScript_engine%29#How_to_run


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:


• 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.


-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.



-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.


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


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


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


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


Appendix I: JavaScript-to-JSON Conversion Table

Date post:	13-Aug-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

Debugging and Testing for a Browser-based …henz/students/richard.pdfDebugging and Testing for a...

Documents