I've added this library in TestComplete with only a few minor tweaks to have it working. In general, I'm finding that adding third party libraries is often pretty easy, as long as the support for the regrettably ancient version of JScript being used by the engine. Anyone else using Underscore or other helpful libraries?

Hi Jose, the library I use the is most json2.js in two main ways: 1. Testing RESTful Web Services (creating and parsing JSON documents) 2. Complex test configuration and key/value mappings I also Base.js for Classes as I wanted a standalone iheritance library, and I prefer the way it works over the others (It's nice being the Tech lead in the test team :) But like you say, I have written a Framework of my own, primarily because Web Testing is only a tiny part of our work. Adding JavaScript libraries to your Project is actually very easy, it's as simple as: 1. Download the library 2. Change the extention form .js to .sj 3. Add as an existing Script Unit There's probably even a case for wrapping them up in a script Extention if you wanted to. However, there may be issues around features not being available due to the JScript engine depending on the library. Phil

"for an HTTP Client I just have a simple synchronous JScript wrapper round MSXML2.XMLHTTP"Yes we do the same. We use TestRail for test case management and access data and post results via the REST apil. We also store stats to mongodb using Sleep.Mongose REST api since there is no TestComplete driver.I've asked SmartBear to implement a modern http client, but they refuse, saying we should buy "SoapUI" even though it has nothing to do with our usage pattern. I think a modern http client should now be considered a requirement, it's not just used for testing. I hope they will soon change their stance on this. We should not have to use this ancient ActiveX technology.

Just as a matter of interest, we recently made an architectural decision to wrap all “static” JavaScript libraries (third party and internal) in Script Extensions. The primary motivator behind this was json2.js throwing uncatchable exceptions for invalid JSON documents, the reason they are uncatchable being that Script Unit level exceptions can only be caught in the Script Unit in which it is thrown. In external Script Units, any exceptions thrown by a function within a JavaScript object cannot be caught (which is what is happening in json2.js). To avoid this, we wrap the JavaScript library in a Script Extension which provides Property and Function accessors which wrap the calls to the JavaScript library functions in try/catch blocks. This has the following benefits: 1. Exceptions can be either handled or rethrown to be caught by other Script Units 2. Can control access to functions in the JavaScript libraries (not all functions are useful, usable or desirable within the Test Complete runtime to be made public) 3. Makes the functions available in the Test Complete code editors intellisense. To minimise the workload around this, I have created some scripts that process a csv file which contain all the information required to create the wrapped property and function wrappers as well as the Description.xml file. Regards, Phil Baird

Hi Big Cat, unfortunately, it's not as straight forward as I had first thought as a bit of trial and error has revealed Exceptions thrown in a script Extension can't (surprise surprise) be caught externally This means the wrapper Script Extension cannot throw Exceptions, instead, I have it returning Exception objects, then, to catch these I have the following in a common script unit: function handle( result, handler, evaluator ) { if( ( ( ! evaluator ) && ArcInnovations.ExceptionFactory.isException( result ) ) || evaluator( result ) ) { if( handler ) { return handler( result ); } else { throw result; } } return result; } which is then used similar to the following: function test001() { var result; try { result = Lang.handle( testObj.throwEx( true ) ); Log.Message( result ); } catch( exObj ) { Log.Message( exObj.exceptionString() ); } } It's hacky and clunky but it works, and it's the best I've been able to come up with. Saying that, I do get and this in the intellisense without having to use //USEUNIT etc I was happily surprised that Test Complete Allowed <RuntimeObject Name="_"> in the Description.xml file and created a runtime object _ Phil

Jose,I'm not using it as an extension, just add as a regular reference. Basically you have to create a container for the instance. Here's what I did, you can use other variable names if you don't like these.1) rename the lib to .sj2) at the top of the file add: var _underscore = {}; 3) find the line near the top of the lib that has this code: var root =this; change it to: var root = _underscore; 4) at the bottom of the file, after the lib code add // create the underscore global var _ = _underscore._;

Underscore.js library | SmartBear Community

16 Replies

Philip_Baird
Community Expert
11 years ago

Hi Jose, the library I use the is most json2.js in two main ways:

1. Testing RESTful Web Services (creating and parsing JSON documents)

2. Complex test configuration and key/value mappings

I also Base.js for Classes as I wanted a standalone iheritance library, and I prefer the way it works over the others (It's nice being the Tech lead in the test team :)

But like you say, I have written a Framework of my own, primarily because Web Testing is only a tiny part of our work.

Adding JavaScript libraries to your Project is actually very easy, it's as simple as:

1. Download the library

2. Change the extention form .js to .sj

3. Add as an existing Script Unit

There's probably even a case for wrapping them up in a script Extention if you wanted to.

However, there may be issues around features not being available due to the JScript engine depending on the library.

Phil
mkarlovich
Occasional Contributor
11 years ago
"for an HTTP Client I just have a simple synchronous JScript wrapper round MSXML2.XMLHTTP"

Yes we do the same. We use TestRail for test case management and access data and post results via the REST apil. We also store stats to mongodb using Sleep.Mongose REST api since there is no TestComplete driver.

I've asked SmartBear to implement a modern http client, but they refuse, saying we should buy "SoapUI" even though it has nothing to do with our usage pattern.

I think a modern http client should now be considered a requirement, it's not just used for testing. I hope they will soon change their stance on this. We should not have to use this ancient ActiveX technology.
Philip_Baird
Community Expert
11 years ago

Just as a matter of interest, we recently made an architectural decision to wrap all “static” JavaScript libraries (third party and internal) in Script Extensions.

The primary motivator behind this was json2.js throwing uncatchable exceptions for invalid JSON documents, the reason they are uncatchable being that Script Unit level exceptions can only be caught in the Script Unit in which it is thrown. In external Script Units, any exceptions thrown by a function within a JavaScript object cannot be caught (which is what is happening in json2.js).

To avoid this, we wrap the JavaScript library in a Script Extension which provides Property and Function accessors which wrap the calls to the JavaScript library functions in try/catch blocks. This has the following benefits:

1. Exceptions can be either handled or rethrown to be caught by other Script Units

2. Can control access to functions in the JavaScript libraries (not all functions are useful, usable or desirable within the Test Complete runtime to be made public)

3. Makes the functions available in the Test Complete code editors intellisense.

To minimise the workload around this, I have created some scripts that process a csv file which contain all the information required to create the wrapped property and function wrappers as well as the Description.xml file.

Regards,

Phil Baird
Philip_Baird
Community Expert
11 years ago

Hi Big Cat, unfortunately, it's not as straight forward as I had first thought as a bit of trial and error has revealed Exceptions thrown in a script Extension can't (surprise surprise) be caught externally

This means the wrapper Script Extension cannot throw Exceptions, instead, I have it returning Exception objects, then, to catch these I have the following in a common script unit:

function handle( result, handler, evaluator ) {

if( ( ( ! evaluator ) && ArcInnovations.ExceptionFactory.isException( result ) ) || evaluator( result ) ) {

if( handler ) {

return handler( result );

} else {

throw result;

}

}

return result;

}

which is then used similar to the following:

function test001() {

var result;

try {

result = Lang.handle( testObj.throwEx( true ) );

Log.Message( result );

} catch( exObj ) {

Log.Message( exObj.exceptionString() );

}

}

It's hacky and clunky but it works, and it's the best I've been able to come up with.

Saying that, I do get

and this

in the intellisense without having to use //USEUNIT etc

I was happily surprised that Test Complete Allowed <RuntimeObject Name="_"> in the Description.xml file and created a runtime object _

Phil
mkarlovich
Occasional Contributor
11 years ago
Jose,

I'm not using it as an extension, just add as a regular reference. Basically you have to create a container for the instance. Here's what I did, you can use other variable names if you don't like these.

1) rename the lib to .sj

2) at the top of the file add:

var _underscore = {};

3) find the line near the top of the lib that has this code:

var root =this;

change it to:

var root = _underscore;

4) at the bottom of the file, after the lib code add

// create the underscore global

var _ = _underscore._;
Philip_Baird
Community Expert
11 years ago
Hi Big Cat, I use Base.js for an inheritance library and json2.js for, well, JSON support and nothing else.

When I first started using Test Complete I considered using support libraries and tried to approach developing tests as I would writing a Web app.

Honestly, the Test Complete runtime is weird, and is nothing like a Browser, I pretty much ditched every design pattern I knew and started afresh and came up with patterns more suited to the way Test Complete works.

There are also Test Complete objects like aqFile, aqDateTime, aqString etc which provide alot of the functionality JavaScript support libraries offer anyway so their usefulness for me diminished.

Regards,

Phil Baird
mkarlovich
Occasional Contributor
11 years ago
Yes the TestComplete runtime is bizarre. I honestly know far, far more about JavaScript than I intended to learn trying to puzzle out and work around the weird behavior. If TestComplete wasn't a tool already in place where I work, I would have some pretty serious objections, which I hope SmartBear will fix. It needs upgrade JavaScript engine and IDE improvements.

I'm using underscore, underscore.string, yaml.js, json2, and xml2json currently and will likely add even more as needed. Underscore was a huge improvement in capability.
Philip_Baird
Community Expert
11 years ago
I think it really comes down to what you are testing, I work primarily in the Oracle OSB/SOA space, lots of database, SOAP and REST Web Services and FTP operations, all mostly back end stuff and I can get by with an old version of JScript, I'm just glad work didn't decide to use VB Script!

Acutally, the most important thing in Test Complete for me is the abliity to write class libraries in C# and access them via the CLR Bridge, this has proven quite helpful to me.

But yeah, in your case I can see how using JavaScript libraries and having a modern JScript engine would be a huge advantage.

Phil
jose_pita
Super Contributor
11 years ago

Hey guys,

When you say you use those libraries, what do you mean? You just have the library js file and call the functions in it when you need it right? I build my own libraries as I need.

If you can give me some pointers on wich libraries I should use (I mainly test front-end of an web app on IE) I'd be much appreciated.

And yes, I totally agree on the IDE and javascript engine issues, many people have complained about it, don't know if smartbear has done anything about it on TC10.
AlexKaras
Champion Level 3
11 years ago
Hi,

> There are also Test Complete objects like aqFile, aqDateTime, aqString etc

> which provide alot of the functionality JavaScript support libraries offer anyway

> so their usefulness for me diminished.

The only note is that you are binding yourself to the given language when you start using some third-party library. If you are working for a single project / employer this might be quite acceptable.

But if you reuse test code for different projects that use language other than JScript, you have no chance but to re-create everything from a scratch. Whereas, in case of using built-in objects, you are getting portable code that requires just a syntax corrections, that are done, usually, pretty easy.

Because of this, my preference is to use native TestComplete programming objects as much as possible, even if / when they have exactly matching equivalents in the current project language.