TestAPI. getTestCases returns suite instead of the list of suite's TestCases

[kneradovsky]

The call to the testApi.getTestCases(project,plan,suite) return the Suite itself instead of the SuiteTestCase[].

The routeValues for that calls lacks 'action' parameter

[kneradovsky]

release 5.1.2 fixes that issue

[kneradovsky]

Still lacks action field in getTestCases call.

[luker2]

I had to make this same modification. Not to hijack, but because this typescript project actually installs thru npm as built javascript, is it possible for me to create my own fork with this change and point my package.json at that fork?

[stephenmichaelf]

@luker2 You are always welcome to fork any open source code :) I will check into this and see if we can get it resolved. If there is an easy fix feel free to create a fork and do a PR against this repo with the change and we can review it.

[luker2]

@stephenmichaelf Thanks! Sorry I wasn't very specific... I am actually more confused HOW to fork this project. If I npm install the original vso-node-api, it installs to my project as [built] JavaScript in node_modules. If I make my own fork and point to it, it installs into node_modules as TypeScript. Do I then need to build it myself or what's the best way to accomplish this?

[stephenmichaelf]

No problem! If you click the fork button on the main vsts-node-api page:

It will create a fork in your own account(looks like you did this). Make sure to keep it up to date by updating from the latest in the fork. It may be easiest for now to delete your fork and take a new one as it seems like it has been a while since you forked.

After you do that, you can create a branch on your fork and start making changes. Commit them to the branch on your fork.

I think you are asking the best way to then test those changes? When you run the build it will generate the built js files long with the .d.ts files in the _build folder underneath the vsts-node-api-folder, it looks something like this:

For local testing you can copy the entire contents of that folder to: your_project/node_modules/vsts-node-api , make sure to delete all the contents in that folder before doing this. You can then run your code and see if it works.

Once that's done you can create a PR against master in the vsts-node-api repo and we can review it together.

If you run into issues or if I misunderstood please let me know :) Another easy way to test is to take a look at our samples folder. You can pick one of the samples, comment the contents out, and add your own test to validate your changes. To run it do:

npm run samples foo

Where foo is the name of the samples file you want to run. This will give you a quicker dev loop to test changes. Then once you've verified it this way you can do the test above with your own code.

[luker2]

@stephenmichaelf Very straightforward, thanks!

I have limited knowledge of both TFS and this project, so right or wrong, my initial goal wasn't really to create the PR myself, but rather fork, make the fix, and use it in my own project.

I'd assume there are other circumstances where devs want to fork something for their own use but it doesn't make sense to PR. So yes, it works locally to build and copy-paste the compiled .js into node_modules, but what if I actually want to check-in those (forked) changes to my project and have my project build and run somewhere else? Would I need to modify my own build process at that point? In vanilla JS it seems I could just point to my own fork in package.json

[stephenmichaelf]

@luker2 Seems like that may work. I haven't done it before.

One thing to keep in mind is that you will want to keep your fork up to date with master(pulling in latest changes) otherwise your version of vsts-node-api will get stuck in time and may break in the future.

If you aren't comfortable looking at making the change I can dig in to this more and see if it makes sense to add :)

[stephenmichaelf]

@kneradovsky @luker2 I just looked at the code:

It looks like the method does return an array of SuiteTestCase. Could you upgrade to the latest version (6.3.2) of the library and see if it's fixed for you?

[luker2]

Updating to 6.3.2 fixed it! I had to get my auth switched over from the NTLM handler to PAT because of #114 but then it worked.

Thanks for all the help!

[stephenmichaelf]

Awesome! Closing :)

[luker2]

@stephenmichaelf I'm sorry, not fixed. Not sure what result I was looking at when I said that.

kneradovsky submitted #105 which would have been the same fix I made locally.