Hi, I want to know which commands should output that tree-like view of JSON data.
in list-deployment-policies what 'Accessibility' means? How i should retrieve it from the JSON response? +---------------------+---------------+ | Id | Accessibility | +=====================+===============+ | deployment-policy-2 | 1 | | deployment-policy-1 | 1 | +---------------------+---------------+ There are couple of commands that gives me errors when I send the request, I have to check that too. I'd do the demo as soon as I finished the document, because I want to know everything is working as expected :) Few more commands to go. Hi Milindu, Great work so far! Could you mention what commands and outputs are less clear? Regards, Chamila de Alwis Committer and PMC Member - Apache Stratos Software Engineer | WSO2 | +94772207163 Blog: code.chamiladealwis.com On Sun, Aug 9, 2015 at 1:59 PM, Milindu Sanoj Kumarage < agentmili...@gmail.com> wrote: > Hi, > > I have finished implementing all the CLI commands, except very few which I > have some doubts ( like, how the output should be presented ) :) > > I started writing a document explaining each and every command with their > expected outputs ( when correct params are given, when no params are given > and when wrong params are given ) I will continue writing the test cases > based on them. > > As discussed on Hangout, I will do a demo, record it and share soon :) > > On Wed, Jul 29, 2015 at 10:34 AM, Milindu Sanoj Kumarage < > agentmili...@gmail.com> wrote: > >> Hi, >> >> I could finish most of the listing command and now working with the >> create and update commands. I'm running Java CLI to get an idea how the >> output should be presented. Had to fix some issues related to that "-" >> issue also, regarding auto-completion. I started writing test cases for >> utility methods, and will start writing test cases for Stratos specific >> ones this week. I'm using Tox to run my tests on different Python versions, >> 2.x ones and 3.z ones. >> >> On Thu, Jul 9, 2015 at 2:52 PM, Milindu Sanoj Kumarage < >> agentmili...@gmail.com> wrote: >> >>> Hi, >>> >>> I invested last 2 week on some research on Testing frameworks and >>> Security Certificates. CA Bundles and Pem files were something I had no >>> experience, therefor I studied on that. Studied Java security API and >>> Stratos's Java CLI's Certificate handling codes ( Keystores, etc ). >>> >>> *Testing frameworks* >>> >>> 1. Unittest ( docs.python.org/2/library/unittest.html ) [ PSF( >>> GPL-compatible ) ] >>> >>> Python's unit testing module since 2.7. Very similar to JUnit for >>> Java. Gives very descriptive outputs when found assertion errors. >>> >>> 2. Unittest2 ( pypi.python.org/pypi/unittest2 ) [ BSD ] >>> >>> unittest2 is a backport of the new features added to the unittest >>> testing framework in Python 2.7 and onwards. Supports back to Python 2.4+. >>> >>> 3. PyTest ( pytest.org/ ) [ MIT ] >>> >>> Very popular unit testing tool which is an alternative to Python’s >>> standard unittest module. Gives very descriptive outputs when found >>> assertion errors. Integrates nicely with setup.py. Python 2 and 3 >>> compatible. >>> >>> 4. Nose ( nose.readthedocs.org/en/latest ) [ LGPL ] >>> >>> Nose extends unittest to make testing easier. Same as PyTest. >>> Python 2 and 3 compatible. >>> >>> 5. Tox ( tox.readthedocs.org/en/latest/ ) [ MIT ] >>> >>> Tox is a generic virtualenv management and test command line tool. We >>> can setup several Python virtual environments and run our tests on those >>> environments. This is a very useful tool to ensure the compatibility with >>> Python 2 and Python 3 versions. PyTest, nose and unittest modules are >>> compatible with tox. Able to easily integrate with continuous integration >>> servers like Jenkins. >>> >>> 6. Doctest ( docs.python.org/2/library/doctest.htmlt ) [ PSF( >>> GPL-compatible ) ] >>> >>> Python module that checks for interactive Python sessions in >>> docstrings, and then executes those sessions to verify that they work >>> exactly as shown. >>> >>> 7. Atheist ( arco.esi.uclm.es/~david.villa/atheist/html/ ) [ GFDL ] >>> >>> A great tool for command line testing, it issues the commands to the >>> underlying shell and compares the output with the intended output. Now >>> discontinued but bug-maintained. >>> >>> 8. Prego ( bitbucket.org/arco_group/prego ) [ GPLv3+ ] >>> >>> Successor of Atheist, which provides support to run shell commands on >>> background, send signal to processes, set assertions on command stdout or >>> stderr, etc. Very suitable in CLI testing tasks. >>> >>> 9. ScriptTest ( pythonpaste.org/scripttest/ ) [ MIT-style permissive >>> license ] >>> >>> Something like Prego, but seems less features. >>> >>> 10. Behave ( jenisys.github.io/behave.example/ ) [ BSD ] >>> >>> A BDD framework and a cucumber-clone for Python. Cucumber is a nice way >>> for feature testing where we define the features in simple English and that >>> will become the tests. >>> >>> >>> I definitely will be using Tox because it makes us test the Python CLI >>> on different Python versions. But Tox alone can not test the CLI. We have >>> to us some other testing framework on Tox. I'm wondering what to use where. >>> We can use PyTest for unit test Stratos.py which calls the Stratos RESTAPI. >>> But we have to test the CLI functionalities also, using some kind of CLI >>> testing tool. I think I need some advice here :) >>> >>> Meanwhile, I continued implementing other "list" CMD actions in Python >>> CLI. I see some repetition in error code handling stuffs, I'm thinking of a >>> way to write a general method for error handling and error reporting. >>> >>> >>> >>> >>> >> >
