Add Unit and Functional Tests #34
Conversation
Unit Tests added for - iSh, iQsh, iCmd function (commandsUnit.js) - iConn methods, stubbed out run method - iPgm methods - iSql methods - xmlToJson function Functional tests added for - iDataQueue Class methods - iNetwork Class methods - iObj methods - iPgm methods - iProd methods - iSql methods - iUserSpace methods - iWork methods Removed test.js - Moved functional tests from test.js to the appropriate class test Added utils.js - contains helper function return transports - returns iConn objects intialized to transports - used to dynamically generate functional tests that only differ by iConn object used for transport Added test/README.md - provides instructions to setup and run tests - lists available environment variables to configure tests
ixml.js - line 293 changed const to let ran into reassignment error with const - changed iXmlNodeSqlParmOpen set io attribute, incorrectly set name attribute before xmlToJson - When converting <sql> xmlOut stmt: property would return ']]>' from CDATA output - Example: "stmt":"SELECT '' AS BLANK, STATE FROM QIWS.QCUSTCDT]]>" - Not sure if every version of XMLSERVICE adds CDATA to returned statement. - Added a check to see if the matched success string contains CDATA and replaced extra characters. iConn.setTimeout() - could not be set, if condition checked flag instead of seconds iSql.rowCount() - added check to allow optional options object iSql.count() - called iXmlNodeSqlRowCount instead of iXmlNodeSqlCount iProd.getProductInfo - Fixed issue that occured when calling with (productId, cb) signature - the callback function definition was being appended to the options causing the pgm call to fail
- moved idb-connector to optional deps - added idb-pconnector to optional deps - added sinon - for (mocking/stubs) to dev deps
|
Why does the ds in the first parm need to have the same pattern of data types repeated 197 times? This looks good, I have a few comments I will add in the morning after I download and try on the IBM i. |
|
I added a README in the test directly that should help you get it setup.
I asked myself the same question in the code I noticed for loop that adds to outBuf, you guessed it 197 times |
|
My thoughts:
I followed the instructions to set up the config and start up the HTTP server, set up my environment variables, but I'm not having any luck getting any more tests to pass.
Once I can get all of the functional tests running, these tests will be super helpful for making sure our 1.0 changes don't break anything! Also, great job finding and fixing bugs exposed through the tests. |
|
It repeats 197 times because that's the max amount of structs declared in the second parameter. Of course, the better way is to use an array: <ds dim="197">
<data type='7A'></data>
<data type='5A'></data>
<data type='6A'></data>
<data type='2h'></data>
<data type='7A'></data>
<data type='10A'></data>
<data type='10A'></data>
<data type='1A'></data>
<data type='1A'></data>
<data type='2A'></data>
<data type='14A'></data>
<data type='132A'></data>
</ds> |
@markdirish For the functional tests we could and should add more verification ensure the data returned from the object property is is as expected. Although many properties return values based on dynamic values: dates, job numbers, users, etc that could vary each run. Which make it difficult to assert the value of the property in the test. For these cases how do we ensure the value is appropriate? For example |
There was a problem hiding this comment.
We might have to talk about whether file-level or class-level constants should be UPPERCASE or just standard case (with eslint suggesting everything should be const).
Also my previous comment about maybe getting more robust tests of the return values, maybe something like a regex to check that at least the pattern of the return value matches something sane if we can't test the actual value.
Other issues are mostly fixed in our v1.0-dev branch, and are focused on style over actual substance.
Going to approve this, because then we can ask others to write tests for changes that they want to merge in.
Changes made in these commits (git log):
Update package.json
Fixed some issues found during unit testing
Added unit and functional tests
Adding functional and unit tests to version 0.1.6 to serve as a common base for future tests.
As we continue to make changes to reach v1.0 we can pull in and build on the tests started here and confirm we are keeping compatibility with this version.
Along the way found some issues some I was able to workaround and resolve (listed below)
Others are still present in the test suit and skipped for now.
For example, when using rest transport on
getInstalledProductstest case iniProdFunctional.jsit fails with Server response code 414 URI Too Long.My thought is that the XML input encoded within the URL GET request is too large causing the test to fail.
The xml input is rather large:
I will open an issue addressing this.