Add template for "New TestCase"

Hi Christian, I had already answered you on SF :D non sure why you didn't get a notification about that.

I think handling the stuff here on track-hacks may be better, though, since it's more thoroughly used.

I'll paste here the comment I made on SF:

Hi Chris, thanks for your interest in this plugin!

I like your idea of adding test case templates, even more because we at work actually use them (by copying-pasting a template text into the pages).

Some users don't have this good practice, out of lazyness, so we now have good and bad test cases :(

An automatic template would have helped.

We actually also have ticket templates, by means of this plugin found on track-hacks: http://trac-hacks.org/wiki/TracTicketTemplatePlugin

Here, well, users just stopped using them, leaving all fields blank or removing the template altogether, so I eventually disabled the plugin.

Anyway, we may have a similar approach for this feature, so to have an admin page where we define the template(s). Initially we can have just one. If required, we may add the ability to add more than one later.

(I'm speaking of "we" since you seem willing to help, and I'd appreciate it a lot!)

What about having templates for test catalogs too? If you are wondering whether test catalogs can actually have a description text then, well, I may have hidden this a littlebit... But they are wiki pages anyway, so the user can always edit the wiki page and write something inside it => It will become the test catalog description.

Then, when creating a test catalog or a test case, the code inside TestManagerSystem?.process_request() method, around line 297 for test catalogs and line 408 for test cases in api.py, should see if a template has been defined for the artifact type and, in case, set it as the test catalog/test case description (last argument to the constructors).

I think this would be the best approach. What do you think?

Ciao, Roberto

Hi Roberto,

all right, please give me a week and I'll try to create a patch first for adding a single template for TestCase?. But I've to warn you... I'm no python programmer :-))

Have a nice weekend, Christian

Hi Roberto,

I've started to implement the template-administration but now I'm stuck because I need 2 more tables. I simply tried to add them to the SCHEMA definition in model.py but when running "trac-admin ... upgrade" it fails (error messages is that "relation testcase already exists"). It seems that your tracgenericclass does not really do an update, right? Or do I simply miss something?

What is the correct way to add tables to an existing installation of TestManager??

Thanks a lot, Christian

Hi Christian, you touched a good point, actually the tracgenericclass does not implement database upgrade yet, but only creation.

I've made a little patch for tracgenericclass and testmanager (on top of the new 1.4.6 release), which is attached to this ticket.

You should be able to define a new table in TestManagerModelProvider?.SCHEMA and correctly trigger a database upgrade.

Let me know if it works.

Thanks for your help! Ciao, Roberto

Upgrade support patch

Hi Roberto,

thank you for your quick response and patch! But I'm sorry that it doesn't work (or I did something wrong :-)).

Here's what I've added to SCHEMA:

                'testmanager_templates_test':
                    {'table':
                        Table('testmanager_templates_test', key = ('id'))[
                              Column('id'),
                              Column('name'),
                              Column('type'),
                              Column('description'),
                              Column('content'),
                              Index(['id'])],
                     'has_custom': False,
                     'has_change': False}

(I currently named the table to add 'testmanager_templates_test' as I've already added a table manually so that I can go on coding :-))

When running the upgrade I get:

InternalError: current transaction is aborted, commands ignored until end of transaction block

and trac.log shows:

2011-06-19 22:27:19,518 Trac[env] INFO: testmanager.model.TestManagerModelProvider upgrading...
2011-06-19 22:27:19,608 Trac[model] DEBUG: Need to create db tables for class 'testmanager_templates_test'.
2011-06-19 22:27:19,609 Trac[model] INFO: Upgrading DB...
2011-06-19 22:27:19,610 Trac[model] INFO: Creating base table testmanager_templates_test...
2011-06-19 22:27:19,610 Trac[model] DEBUG: CREATE TABLE "testmanager_templates_test" (
    "id" text PRIMARY KEY,
    "name" text,
    "type" text,
    "description" text,
    "content" text
)
2011-06-19 22:27:19,611 Trac[model] ERROR: ('InternalError', '<no args>', ['  File "/usr/lib/python2.6/site-packages/TracGenericClass-1.0.6-py2.6.egg/tracgenericclass/model.py", line 1286, in upgrade_db\n    cursor.execute(stmt)\n', '  File "/usr/lib/python2.6/site-packages/trac/db/util.py", line 66, in execute\n    return self.cursor.execute(sql)\n'])
2011-06-19 22:27:19,612 Trac[model] ERROR: Exception during database creation.
2011-06-19 22:27:19,614 Trac[console] ERROR: Exception in trac-admin command:
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/trac/admin/console.py", line 107, in onecmd
    rv = cmd.Cmd.onecmd(self, line) or 0
  File "/usr/lib64/python2.6/cmd.py", line 218, in onecmd
    return self.default(line)
  File "/usr/lib/python2.6/site-packages/trac/admin/console.py", line 266, in default
    return cmd_mgr.execute_command(*args)
  File "/usr/lib/python2.6/site-packages/trac/admin/api.py", line 123, in execute_command
    return f(*fargs)
  File "/usr/lib/python2.6/site-packages/trac/env.py", line 782, in _do_upgrade
    self.env.upgrade(backup=no_backup is None)
  File "/usr/lib/python2.6/site-packages/trac/env.py", line 525, in upgrade
    with_transaction(self)(participant.upgrade_environment)
  File "/usr/lib/python2.6/site-packages/trac/db/api.py", line 77, in transaction_wrapper
    fn(ldb)
  File "/usr/lib/python2.6/site-packages/TestManager-1.4.6-py2.6.egg/testmanager/model.py", line 663, in upgrade_environment
    upgrade_db(self.env, self.SCHEMA, db)
  File "/usr/lib/python2.6/site-packages/TracGenericClass-1.0.6-py2.6.egg/tracgenericclass/model.py", line 1286, in upgrade_db
    cursor.execute(stmt)
  File "/usr/lib/python2.6/site-packages/trac/db/util.py", line 66, in execute
    return self.cursor.execute(sql)
InternalError: current transaction is aborted, commands ignored until end of transaction block
InternalError: current transaction is aborted, commands ignored until end of transaction block

What did I wrong?? Christian

Hi Christian, I cannot reproduce your error... it works for me with both Trac 0.11.7 and 0.12.2.

Anyway, I was thinking more about it and actually testmanager already has a configuration table, currently used to store current last ids for various objects.

You may use this same table to store the test case template.

If you look at model.py (the testman4trac one) around line 655 you'll find how to store default value for your property:

# Create default values for configuration properties and initialize counters
self._insert_or_update('testconfig', 'NEXT_CATALOG_ID', '0', db)

If you look at api.py (the testman4trac one) in get_next_id() method you will find how to get and update values.

Hope this helps! Ciao, Roberto

Hi Roberto,

strange... the problem also is here when I add the Testmanager-Plugin for a new trac instance (then with table "testplan", no testmanager tables will be created). But I'll postpone the upgrade and continue now with my manually created table.

I'm not sure what you're thinking about the "configuration table"... My intention was to have one table holding the templates (name, type, short description and content) and a second table which describes the relation: which testcatalog should use which template (which template for TestPlan? and which for TestCase?).

What do you think about this approach?

Christian

Hi again :-)

did a short further test by switching back the model.py of TracGenericClass? and now at least I can activate TestManager? in a new project.

That's completely strange as I can see the only difference in the new model.py is that it checks before wheter the table already exists or not. Here's what I've found about the error-message ("current transaction is aborted....")

This is what postgres does when a query produces an error and you try to run another query without first rolling back the transaction. To fix it, you'll want to figure out where in the code that bad query is being executed.

It seems that the exception cause by the "select count (*) from ..." at line 1269 is not caugth correctly and therefore the following "create table" fails.

Why this only happens here in my environment... I don't know... Probably my PostgreSQL version (9.0.3) behaves different than yours.

As said that I'm a Python novice... what can I do to improve the handling of the exception at the "select count..." ?

Christian

And it's again me :-))

Hi Roberto,

I've fixed the upgrade-problem by patching model.py of TracGenericClass?:

--- model.py-old 2011-06-20 10:19:04.593103212 +0200
+++ model.py 2011-06-20 12:15:47.829353466 +0200
@@ -1264,17 +1264,11 @@

             tname = tablem.name

-            try:
-                cursor = db.cursor()
-                cursor.execute("select count(*) from %s" % tname)
-                cursor.fetchone()
-
-                # The table already exists. Skip it.
-                # TODO: Alter table to fit any difference with the new definition
-                continue
-            except:
-                # OK, need to create the table
-                pass
+     cursor = db.cursor()
+     cursor.execute("select exists(select * from information_schema.tables where table_name ='%s');" % tname)
+     row = cursor.fetchone()
+     if row[0]:
+         continue

             cursor = db.cursor()
             key_names = [k for k in tablem.key]

I've found this modified test if a table exists and it works perfectly fine here on my system. Could you please try if it's also working for you and maybe add it to the official code of TracGenericClass??

I think that's a better way to check if a table exists because it avoids the problem of handling exceptions in python and dealing with transaction in PostgreSQL...

Christian

Hi Christian, cool solution! I'll try it asap and see if it works with sqlite (I'm not using postgre :D).

My intention was to have one table holding the templates (name, type, short description and content) and a second table which describes the relation: which testcatalog should use which template (which template for TestPlan? and which for TestCase?).

So, if I understand it correctly, you are thinking about adding the ability to define multiple templates. The user would select the artifact type (i.e. test catalog, test plan, test case, ...), and will be able to add more than one template for each type.

This would be interesting and very flexible.

Did you already think about the management use cases?

• Defining a template
• Browsing templates
• Modifying a template
• Deleting a template

The way I see it is having a table in a new "Test Templates" section in the Admin tab.

Additionally, what about the template selection use case, at the time a new test catalog, for example, is created?

Will there be a default template that is used automatically, or will the user have to select one before opening the new wiki page for editing?

Good job! Ciao, Roberto

Hi Roberto,

so we have a little problem now, as far as I know, my solution for checking whether the table exists or not, is too specific... it will only work for PostgreSQL. I'll search for a better method as far as I've time for that.

Yes, you're right, I've started with implementing the ability to have multiple templates, as it turned out to be easier than trying first with a single template and then implement multiple templates later :-)

Management of the templates is almost finished.

One thing is that I've forgot to mention up to now: I'm 'only' the admin of our Trac server, not a user and therefore have absolutely no knowledge about how to use the TestManager?...

What I've thought is, that a TRAC_ADMIN would be able to define one (only one) template for TestCase? and one for TestPlan? for each TestCatalog?. But from your response I understand that this will not fit to the users need, right? So we probably need a matrix for selecting more than one template (for TestCase? and TestPlan?) for each TestCatalog?.

Is that what you'd in your mind?

Christian

Hi Christian,

What I've thought is, that a TRAC_ADMIN would be able to define one (only one) template for TestCase? and one for TestPlan? for each TestCatalog?.

I think this would be enough, no need to have multiple templates per object type.

Also, test plans can't have a specific text, they are just a specific instance of the corresponding test catalog.

This simplifies things down to having just one template for test catalogs and one for test cases.

I still think that you may simply use the available "testconfig" table, instead of creating one specifically for storing these templates.

You may define a default template in model.py (the testman4trac one) around line 655:

# Create default values for test templates
self._insert_or_update('testconfig', 'TEST_CATALOG_TEMPLATE', 'Bleah Bleah Bleah', db)
self._insert_or_update('testconfig', 'TEST_CASE_TEMPLATE', 'Bleah Bleah Bleah', db)

and then update these same table rows when the User edits the templates in the Admin panel.

Ciao, Roberto

Hi Roberto,

I think I have now a first draft of the template-extension for you to look at. What would you prefere? A zip-file with added/modified files or a diff-file?

Christian

Hi Christian, that's great!

If you wish you can attach to this ticket a zip file with the added/modified files (with relative paths).

Thanks! Ciao, Roberto

Hi Roberto,

sorry for the delay but we had a little party in our company last evening :-))

Please see the attached template.zip and hopefully it's close to that what you'd in your mind when thinking about templates :-)

Christian

Extension for having templates

Hi Christian, you did a tremendous job!

I could try it very quickly today (after I fixed the indentation, which was completely messed up... there may be something wrong with your editor?), and I was impressed by your work.

I found some small bugs, and I'd like to make use of a couple of utility functions I made to ensure compatibility with both Trac 0.11 and 0.12.

I would also like to make sure every message is I18N-compliant.

Cool thing you also made a Settings page :D

I'll try to look at it better during the w/e, and get back to you asap.

Thanks! Ciao, Roberto

Hi Roberto,

fine to hear that you're lucky with my modification :-)

Regarding the indentation... I don't know why it's messed up, I normally trust in "vi" with auto-indentation switched on. But as already said, I'm no real programmer, just a poor sysadmin who sometimes wishes back the good old times when I did some more programming :-))

Yes, you're right, there can (or will) be some incompatibilites to Trac 0.11, I never tested it as we have all our servers here on 0.12. Thanks a lot for fixing this!

As I've "finished" the templating, I'd a closer look at the upgrade-problem within model.py of TracGenericClass?. A possible fix (that's working here with PostgreSQL) would be to add a "db.rollback()" in the except clause around line 1275 (in procedure upgrade_db) and move the final "db.commit()" into the loop "for realm in schema:". I know that's not the best solution, but I think for PostgreSQL (not sure if this also is valid for MySQL) it's the only possible solution.

The problem is that also a "SELECT COUNT (*) FROM..." will start a transaction (if not already within one) and if the table is not existing it causes a exception that must be handled before doing further sql-commands.

Have a nice weekend, Christian

Hi Roberto,

could you please send me back the changes you'd done? I found a little problem: when deleting a template (either for TestCatalog? and for TestCase?), we have to check whether this template are in use before deleting.

And, just for usability, I'd like to add a "preview" to the template editor :-)

Another question: at the "settings" page... shouldn't we also have the possibility to edit the "test-outcomes" and "custom fields" sections?

Christian

Hi Christian, I have the changed code, but I wouldn't like to attach everything here.

If you could write me at my personal email (find it in the README.txt file), I will send you the zip file.

Thanks, ciao. Roberto

Christian, your enhancement has been just shipped with 1.4.7!

Thanks again for your help, and I hope I may ask you for some more help in the future :D