Modify

Opened 3 years ago

Closed 3 years ago

#8907 closed enhancement (fixed)

Add template for "New TestCase"

Reported by: ChristianM Owned by: seccanj
Priority: low Component: TestManagerForTracPlugin
Severity: minor Keywords:
Cc: Trac Release: 0.12

Description

Hi Roberto,

I've already added this on SourceForge, but I'm not sure how often you've time
to look there :-))

When creating a new TestCase, a new Wiki-Page will be opened for editing. At the moment there is only the title added automatically.

What about having a template that will be added to that Wiki-Page (or better said TestCase)? As far as I've seen in the code, this should
not be the biggest problem as the class TestCase has everything that would be needed.

If you like, I could try to provide a patch, but it would be fine to discuss it first... just to be sure to implement it in a way you'd like it :-)
(should it be implemented by a "simple" option in trac.ini? or better implement it
as a "template wiki-page" that will be referenced in trac.ini and then copied when
creating a new TestCase?)

Christian

Attachments (2)

8907_upgrade.zip (16.6 KB) - added by seccanj 3 years ago.
Upgrade support patch
template.zip (18.6 KB) - added by ChristianM 3 years ago.
Extension for having templates

Download all attachments as: .zip

Change History (22)

comment:1 follow-up: Changed 3 years ago by seccanj

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

comment:2 in reply to: ↑ 1 ; follow-up: Changed 3 years ago by ChristianM

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

comment:3 in reply to: ↑ 2 Changed 3 years ago by ChristianM

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

comment:4 follow-up: Changed 3 years ago by seccanj

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

Changed 3 years ago by seccanj

Upgrade support patch

comment:5 in reply to: ↑ 4 Changed 3 years ago by ChristianM

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

comment:6 follow-up: Changed 3 years ago by seccanj

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

comment:7 in reply to: ↑ 6 ; follow-up: Changed 3 years ago by ChristianM

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

comment:8 in reply to: ↑ 7 ; follow-up: Changed 3 years ago by ChristianM

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

comment:9 in reply to: ↑ 8 Changed 3 years ago by ChristianM

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

comment:10 follow-up: Changed 3 years ago by seccanj

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

comment:11 in reply to: ↑ 10 Changed 3 years ago by ChristianM

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

comment:12 follow-up: Changed 3 years ago by seccanj

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

comment:13 in reply to: ↑ 12 Changed 3 years ago by ChristianM

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

comment:14 follow-up: Changed 3 years ago by seccanj

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

comment:15 in reply to: ↑ 14 Changed 3 years ago by ChristianM

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

Changed 3 years ago by ChristianM

Extension for having templates

comment:16 follow-up: Changed 3 years ago by seccanj

  • Status changed from new to assigned

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

comment:17 in reply to: ↑ 16 ; follow-up: Changed 3 years ago by ChristianM

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

comment:18 in reply to: ↑ 17 Changed 3 years ago by anonymous

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

comment:19 Changed 3 years ago by seccanj

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

comment:20 Changed 3 years ago by seccanj

  • Resolution set to fixed
  • Status changed from assigned to closed

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

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.