daluu / extendables Goto Github PK

Unless I'm executing the tests incorrectly...(as I'm just running the runner.someName.jsx scripts under test directory of Extendables via ExtendScript toolkit)...

It appears at last check, the test framework's included test suite doesn't fully pass, under Adobe suite (executed from ExtendScript toolkit) CS6. The failed test cases are noted below, with some additional info.

Would be nice to look into whether the suite ever 100% passed before, and under what Adobe versions does the test get failures, etc. Would be nice to get community input on this as I don't have all the supported/supportable Adobe versions to test with.

Test framework failures:

is entirely CommonJS-compliant
Expected 'index' to equal 'package-b'

has a working code sample that does XML traversal
SyntaxError: Expected: ) in ~/Documents/GitHub/Extendables/examples/xml-traversal.jsx (line 3)

OS: Windows 7/64 6.1 Service Pack 1 (32-bit emulation)
ExtendScript build: 66.489054
ExtendScript version: 4.2.12
path: ~
locale: en_US
app: ExtendScript Toolkit
app version: 3.8

Package test failures:

Template package
has unit tests
Expected false to be truthy.

HTTP requests
has a high-level shortcut for GET requests
Expected 404 to equal 200.
has a high-level shortcut for HEAD requests
Expected 404 to equal 200.
has a high-level shortcut for POST requests
Expected 404 to equal 200.
has a high-level shortcut for DEL requests
Expected 404 to equal 200.
can follow redirects
Expected 404 to equal 200.
can follow redirects manually, using the .follow() method
Expected 404 to equal 200.
is thoroughly stress-tested
Expected 404 to equal 200.

Patch test failures:

runner.patches.jsx fails to complete test execution with the following exception in ExtendScript toolkit:

"result.toLowerCase is not a function" for the following line of code:
line 130 of object.conversions.jsx: 'lower': function () { return result.toLowerCase(); },

Add for tracking purposes. See http://stackoverflow.com/questions/23251887/print-message-on-expect-assert-failure for reference. May be able to just use the workaround as suggested. Hope it works for all expect comparison methods. Otherwise would need to patch expects with enhancement.

Logging for tracking purposes, since original project has no issue tracker. See: https://forums.adobe.com/thread/998305?sr=stream and https://forums.adobe.com/message/3257164.

Logging for tracking purposes, since original project has no issue tracker. See: https://forums.adobe.com/thread/903437

See http://stackoverflow.com/questions/10231646/post-request-for-file-upload-in-javascript-indesign-extendables

The current Extendables HTTP library/module is based on sockets available to InDesign, as Extendables was originally built for InDesign. But not all Adobe applications offer the socket class (e.g. Adobe Illustrator) and the HTTP library/module is not full feature complete (and/or well documented), e.g. see #7.

Therefore, it would be nice to provide an alternate HTTP library/module with the same API but implemented internally using Adobe Bridge/Bridgetalk's HttpConnection class (see Adobe Bridge SDK for the javascript docs on this). The user can then transparently switch libraries w/o changing their code/call signatures, only the include statement will differ.

Or better, yet enhance Extendables to internally toggle loading/selecting the appropriate HTTP library based on configurable setting the user sets. So no need to change includes, etc. just that setting. With default being the socket implementation, since not everyone has Adobe Bridge/Bridgetalk.

Logging for tracking purposes, since original Extendables project this fork is from has no issue tracker.

Use below code to reproduce. Without Extendables, iterating through javascript objects behave as normal. With Extendables included, you need to call hasOwnProperty() method against the current property being iterated to in order to filter out the inherited properties that we don't expect to be dealing with.

#include "../Extendables/extendables.jsx";

var arr1 = ["Saab", "Volvo", "BMW"];
var jsonObj1 = {"firstName":"John", "lastName":"Doe"};
var jsonObjArr1 = { "employees":[
                                    {"firstName":"John", "lastName":"Doe"}, 
                                    {"firstName":"Anna", "lastName":"Smith"}, 
                                    {"firstName":"Peter", "lastName":"Jones"}
                                ]
                  };

for(var prop in jsonObj1){
    if(jsonObj1.hasOwnProperty(prop)){
        alert("has property: " + prop);
        alert("with value: " + jsonObj1[prop]);
    }
    alert("has unfiltered property: " + prop);
    alert("with unfiltered value: " + jsonObj1[prop]);
}

Logging for tracking purposes, since original Extendables project this fork is from has no issue tracker. To reproduce, run this snippet in any Adobe app or ExtendScript toolkit.

#include "pathTo/Extendables/extendables.jsx";
try{
    throw Error("intentional failure");
}catch(e){
    alert("caught: "+e.message);
}finally{
    alert("cleanup");
}

Without Extendables, we see the alerts as appropriate. With Extendables, executing the code brings up ExtendToolkit in debug mode stuck/stopping at the line where error is thrown.

Need to look into what within Extendables causes this.

The Extendables testing module at present has a defined method "as_json" that is currently not implemented.

https://github.com/daluu/Extendables/blob/master/core-packages/testing/lib/index.jsx#L67

It would be ideal to implement that or an alternate version of "to_html" (as in "to_xml" and/or "to_json")

https://github.com/daluu/Extendables/blob/master/core-packages/testing/lib/index.jsx#L86

to provide test results output as JSON or XML for further post processing in whatever tooling the user has, in case the default HTML report is not desirable for test reporting in say a continuous integration build pipeline. And/or for integration with results of other types of tests (e.g. Selenium, API, etc.) for a master test results report.

This probably means creating a version of the HTML template(s) to JSON/XML as well, like report.html

Due to the other issues noted in this project (original source project has no issue tracker), use of Extendables can be problematic in certain situations. It would be most ideal to be able to use only the features one needs within Extendables rather than by default include everything when including Extendables.

At present on brief code review of files in an attempt to fix some other open issues, it appears that Extendables is rather tightly integrated in dependencies between the extended features and requires some time and effort to un-integrate the dependencies or making them "optional" but not dependent.

So this is a ticket that kind of defines two tasks:

1. Look into restructuring Extendables to include/extend only what is needed. And that be configurable somehow. This could be useful to avoid bugs that haven't been fixed from extended features.
2. As item 1 above may be more work, make a fork/alternate version of Extendables that simply has the logger and Jasmine test framework functionality as bare minimum as that is what I currently use it for. Don't care for the other object extension features.