Articles by Kiwi TCMS Team

Kiwi TCMS roadmap for 2018

Hello everyone. As you know Kiwi TCMS has been around for a while and it has gone through some big changes in the last year! It started as an abandoned Django 1.6 project with broken test suite and is now currently running on the latest Django 2.0.1 with Python 3.5! It is clearly a legacy code base!

We, the Kiwi TCMS team, have learned a lot more about the project and this blog post describes our roadmap for 2018 in terms of technical work and community engagement. The general technical direction is cleaner/simpler code, improved UI/UX and more tests!

Make code easier to maintain

The current code is a bunch of very large modules and functions and classes bundled together. It is also old and sometimes looks like spaghetti code. CodeClimate gives us a "D" rating for maintainability with a 1 year estimated effort to fix that. There are 600+ code smells and 600+ duplications detected by CodeClimate. Our goal is to get this number down to zero!

Use pylint and pylint-django

pylint is the standard static analyzer for Python and currently it reports over 4000 errors and warnings when executed against Kiwi TCMS. This is a huge number and it needs to become zero! We've also identified interesting patterns that will make it into pylint and pylint-django plugins!

Render HTML, return JSON

The current state of affairs is a mix and match of everything. There are views that render HTML, others which return pure JSON, other which return HTML encoded as JSON string and probably everything in between. Views that render pages need to do just that and views that are used with AJAX calls from the UI need to return pure JSON! A lot of these are hiding in plain sight and will come to light when we start overhauling the user interface.

Submit forms, post JSON, GET clean URLs

There are lots of forms in Kiwi TCMS. Sometimes they are submitted by the user and other times they are serialized and POSTed by some JavaScript code. This isn't very easy to understand plus this entire home-grown utility code doesn't bring anything useful to the project. All of these need to be identified and cleaned up. JavaScript code needs to send or consume JSON, nothing else!

There are also lots of places where Kiwi issues GET requests with a number of query parameters. Our goal is to minimize these and where possible have the parameters as part of the Django urls scheme, not as query strings.

API layer

The current API module is a bit disorganized. API namespaces don't match the names of the underlying DB models and the API client classes don't match any of the other two! The way we pass parameters and what these parameters are named should match between the client, the RPC method and the underlying model!

In earlier releases we've removed duplicate or similar RPC methods and we think there are more of these that need our love.

Documentation

We've started producing documentation from doc-strings and most of the RPC methods have such. However it is unformatted and barely readable, sometimes even inaccurate. Previous releases made progress on this but there's a lot more to cover.

All RPC methods should be documented first and then the rest of Kiwi's internals to make development easier!

No vendored JavaScript libraries

There are 11 vendored-in JavaScript files that we carry around in Kiwi TCMS. Most notable are jQuery plus a few addons and Handlebars.js. To the extent possible our goal is to use jQuery provided by Django or installed via NPM dependencies!

Less HTML templates with better organization

There are over 100 HTML templates in Kiwi TCMS. There are also email and even JavaScript templates. For example there are get_cases.html and get_review_cases.html which are essentially the same. This is kind of also true for templates used in new and edit views! Such templates should be unified!

Those JavaScript templates need to be totally gone!

All templates are stuffed together in a single directory and their names are not very predictable. They need to be split per application and follow some kind of naming convention.

Modern interface with Patternfly

The UI already uses the Patternfly library for some of its widgets. Most notably the main navigation header. Our goal is for the entire UI to be ported to Patternfly by updating widgets HTML and CSS where needed. This will also help clean things up a lot. At the same time we'll be rethinking how information is organized on screen and how the person interacts with it! Usability suggestions are very welcome!

This move will also help us get rid of the Handlebars dependency which is now used for pop-up dialogs.

JavaScript updates and front-end testing

There's lots of JavaScript code on the front-end and honestly we don't quite know what it does or how it is organized. There are also no tests on the front-end whatsoever!

It is our goal for this to change with the intention to not overdo the JavaScript part and keep things very minimal. At the moment we're thinking about vanilla jQuery that will act as a proxy between the browser and the back-end!

Community efforts

A year ago hardly anybody knew what Kiwi TCMS was, the project didn't even have this name, there was 1 active contributor and hardly any users! Now the community has started to slowly revitalize, we're seeing some contributions from our junior team members (more on this in another blog post) and also seeing folks installing and using Kiwi TCMS and reporting interesting bugs and feature requests around it!

For the upcoming year our goal is to seek active engagement with other open source projects that could make use of Kiwi TCMS and work with them. Kudos to openSUSE for being the first to propose such integration! We're also planning couple of appearances at a few conferences but there's nothing confirmed yet.

Every other contribution in terms of bug reports, new users and feature requests is of course welcome but we're very conscious of the fact that there's tons of work to be done and the team is still very small!

Team wise we'd like to get the existing team members up to speed and tackle the above tasks with priority. This will also help us introduce bug fixes and new features more quickly!

Happy testing!

Kiwi TCMS version 3.49

Happy New Year to everyone. We're happy to announce Kiwi TCMS version 3.49 and the corresponding tcms-api version 1.5.0! This release includes a fair amount of bug fixes and many changes related to Kiwi's RPC layer!

Most importantly Kiwi is updated to Django 2.0.1, the API client no longer supports Python 2 and many RPC methods have been removed or updated. https://public.tenant.kiwitcms.org has also been updated so you can explore the new version.

Changes since Kiwi TCMS 3.48

Enhancements and bug fixes

  • Upgrade to Django 2.0.1
  • Don't log passwords sent via RPC
  • Log XML-RPC requests from anonymous users. Fixes Issue #126
  • Order TCMSEnvValue records by property name and value. Fixes Issue #155
  • flake8 fixes (Anton Sankov)
  • Start building source code documentation from Python doc strings
  • Properly urlencode emails in personal menu links
  • Remove test case import via XML files
  • Use django-attachments for user uploaded files. Fixes Issue #160 As part of this change we no longer copy Plan and Case attachments when cloning these objects.

NOTE: Since django-attachments introduces new permission objects you will have to adjust default permissions for existing users! In order for them to be able to upload/delete their own files they need to have attachments.add_attachment and atachments.delete_attachment permissions.

These same permissions are added by default to the 'Tester' group. If you are running an existing installation registering a new user with Kiwi TCMS will update the default permissions for this group!

Refactoring

  • Remove unused class EditCaseNotifyThread (Chenxiong Qi)
  • Remove model TestPlanActivity (Chenxiong Qi)
  • Remove many unused models and classes
  • Execute tests via manage.py test and drop py.test dependency
  • Remove useless TestTag.string_to_list method. Fixes Issue #106
  • Use settings.AUTH_USER_MODEL in ForeignKey definitions. Fixes Issue #143

Settings

  • Rename EMAIL_FROM to DEFAULT_FROM_EMAIL. Fixes Issue #128
  • Rename FILE_UPLOAD_DIR to MEDIA_ROOT
  • Rename MAX_UPLOAD_SIZE to FILE_UPLOAD_MAX_SIZE
  • New setting DELETE_ATTACHMENTS_FROM_DISK
  • Remove unused XMLRPC_TEMPLATE and TESTOPIA_XML_VERSION

Server side API

  • Migrate to django-modern-rpc and remove home-grown XML-RPC handling code. As part of this change the XML-RPC endpoint has been changed to /xml-rpc/. There's also a new JSON-RPC endpoint at /json-rpc/!
  • Auth.login method now accepts positional parameters username, password instead of dict
  • TestCaseRun.get method now accepts a query dict as parameter
  • TestCaseRun.get_bugs method now accepts a query dict as parameter
  • Remove Build.lookup_id_by_name, Build.lookup_name_by_id RPC methods
  • Remove Product.lookup_name_by_id, Product.lookup_id_by_name RPC methods
  • Remove Product.get_components, use Product.filter_components instead
  • Remove Product.get_plans, use TestPlan.filter instead
  • Remove Product.get_runs, use TestRun.filter instead
  • Remove Product.get_tag, use Tag.get_tags instead
  • Remove Product.get_versions, use Product.filter_versions instead
  • Remove TestCaseRun.filter_count, use TestCaseRun.filter instead
  • Remove TestCaseRun.get_s, use TestCaseRun.get instead
  • Remove TestCaseRun.get_bugs_s, use TestCaseRun.get_bugs instead
  • Remove TestCaseRun.get_case_run_status, use TestCaseRun.get_case_run_status_by_name instead
  • Remove TestCaseRun.get_completion_time, TestCaseRun.get_completion_time_s RPC methods. Instead calculate them on the client side
  • Rename TestCaseRun.check_case_run_status to TestCaseRun.get_case_run_status_by_name
  • TestCaseRun.detach_log will not raise exceptions when deleting logs from non-existing TestCaseRun objects.
  • Remove User.get_me, instead use User.get without parameters
  • Remove Version. and Testopia. RPC modules
  • Update documentation for RPC methods in Auth, Build and Env namespaces. Unformatted documentation is also available for the rest of the RPC methods

tcms-api changes since 1.4.0

  • Update endpoint configuration, compatible with Kiwi TCMS 3.49
  • Drop support for Python 2
  • Remove the internal do_command method which eliminates use of eval()
  • Remove TCMSXmlrpc.get_me() and TCMSXmlrpc.build_get() methods

IMPORTANT: this release introduces new database migrations!

How to upgrade

If you are using Kiwi TCMS as a Docker container then

cd Kiwi/
docker-compose down
make docker-image
docker-compose up -d
docker exec -it kiwi_web /Kiwi/manage.py migrate

Happy testing!

Kiwi TCMS Python API client

We are happy to announce the first official release of the tcms-api package! This is a Python client for Kiwi TCMS.

There are couple of main distinctions in this module:

  • mutable vs. immutable types of objects
  • high-level class interface vs. low-level XML-RPC interface

For more information you should check-out the documentation and the script_examples/ directory.

At the moment the API client is both Python2 and Python3 compatible, however it is tested only under Python3!

A bit of history

The original API client, like Kiwi TCMS itself began its origin under a different name and was created primarily by Petr Splichal. Since then Kiwi TCMS has evolved and we've decided that the API module needs to evolve as well. At the moment the tcms-api module is a bit rough around the edges, its documentation is not really the best one and it's currently advisable to spend some time reading the code to figure out how everything works.

We're going to improve on all of these areas and we need help from the community to do so! Please download the tcms-api module, check it out, write and contribute example scripts (you can use the demo site for this), send us bug reports, suggestions and pull requests!

Happy testing!

Kiwi TCMS version 3.48

We're proud to announce Kiwi TCMS version 3.48! This is the first release to be announced on our blog and it is also an important one!

Kiwi TCMS 3.48 introduces new versions of Django and Patternfly, a Python API client library, many bug-fixes and updated documentation.

Changes since KiwiTCMS 3.44

  • Update to Django 1.11.7 (Mr. Senko)
  • Update documentation including high level information about how data is organized within Kiwi TCMS and how to work with the system. (Mr. Senko)
  • Stop caching report views. (Mr. Senko)
  • Make test execution comments optional. Fixes Issue #77. (Mr. Senko)
  • Escape special symbols when exporting JSON. Fixes Issue #78. (Mr. Senko)
  • Remove Test Run export to XML functionality in favor of API. Fixes Issue #79. (Mr. Senko)
  • Make it possible to search Test Runs via Env properties. Fixes Issue #82. (Mr. Senko)
  • Display Environment properties in Test Run search results. (Mr. Senko)
  • Allow bulk update TestCase.default_tester via email. Fixes Issue #85. (Mr. Senko)
  • Don't crash reports when there are untested TestCaseRuns. Fixes Issue #88. (Mr. Senko)
  • Bind localhost:80 to container:80. Fixes Issue #99. (Mr. Senko)
  • Enable testing with Python 3.6 in preparation for migration. (Mr. Senko)
  • If JIRA isn't fully configured then don't connect. Fixes Fixes Issue #100. (Mr. Senko)
  • Pin patternfly version to 3.30 and update templates. Fixes Issue #120. (Mr. Senko)
  • Show status name rather than status id in TestCaseRun change log. (Chenxiong Qi)
  • [api] Adds a Python API client with changes that make it possible to execute on both Python 2 and Python 3. For now take a look at tcms_api/script_examples/ for examples how to use it.
  • [api] Remove experimental support for Teiid. (Mr. Senko)
  • [api] Cache level defaults to CACHE_NONE if not set. (Mr. Senko)
  • [api] Remove persistent cache, in-memory caching is still available. (Mr. Senko)
  • [api] Remove multicall support. (Mr. Senko)

IMPORTANT: this release introduces new database migrations!

NOTE: the API client has been initially developed as the python-nitrate project by Petr Splichal and other contributors! We've decided to fork their code base into Kiwi's repository and continue further development in a central place. This makes it easier testing the API server and client together and allows us to move more rapidly!

As of now there isn't a lot of documentation and examples on how to use the API client but we are looking to improve this. Additional documentation and examples will be published in the project's repository or on this blog!

How to upgrade

If you are using Kiwi TCMS as a Docker container then

cd Kiwi/
docker-compose down
make docker-image
docker-compose up -d
docker exec -it kiwi_web /Kiwi/manage.py migrate

Happy testing!

Testing, testing. It works!

Welcome to the official website and blog of Kiwi TCMS. We are happy to finally be online!

This website was built with the help of Kaloyan Krastev, Tsvetoslav Garkov and Ivaylo Ivanov who will be joining the project a bit later as well.

In this blog you can expect various news and progress reports around the project, announcement of new releases and future plans. We would love to hear your feedback so please use the comments form below.

Happy testing!

Newer Posts

Page 8 / 8