[ditrack commit] r2398 - issues/data/i188

[Ivan Glushkov]

Author: vss
Date: 2007-11-26 23:44:13 -0800 (Mon, 26 Nov 2007)
New Revision: 2398
issues/data/i188/comment4
i#188: consolidate test repositories
* reopened
The current approach of crafting the "expected output" in each individual
testcase doesn't seem right. The code is highly duplicated and so we won't be
able to leverage the "consolidation" the issue is all about.
I can see two approaches to solve the problem.
1. Include the "expected output" for typical operations (commit on
just-checked-out test repository) into the tarball along with the repository
dump itself. Each testcase would invoke a method to diff against this output.
2. Extend recently implemented methods commit() and new_issue() to [optionally]
prepare the expected output (possibly using passed arguments like owner and due
version) and diff against that.
I'm more in favor in option 2. Anyhow, no code should be duplicated.

I don't understand the second method. It'd allow to check only
'commit' command and result of the 'new_issue' method?

I've just added new action to the "act" command ("re"). So the output
of it [act command] changed. So i needed to change a lot of tests.
This difference of output would be known only to the person who made
changes in the ditrack functionality. So "commit" and "new_issue"
methods of dttest package could't guess smth if i hadn't given them
any pattern.

My proposal:
1. Surely add some pattern outputs for typical operations to testcase repository
2. Modify 'dttest.dt' method so it'll analyze the given command and
use the appropriate pattern from test repository.

Opinions?

Ivan.

[Vlad Skvortsov]

Post by Ivan Glushkov

The current approach of crafting the "expected output" in each individual
testcase doesn't seem right. The code is highly duplicated and so we won't be
able to leverage the "consolidation" the issue is all about.
I can see two approaches to solve the problem.
1. Include the "expected output" for typical operations (commit on
just-checked-out test repository) into the tarball along with the repository
dump itself. Each testcase would invoke a method to diff against this output.
2. Extend recently implemented methods commit() and new_issue() to [optionally]
prepare the expected output (possibly using passed arguments like owner and due
version) and diff against that.
I'm more in favor in option 2. Anyhow, no code should be duplicated.

I don't understand the second method. It'd allow to check only
'commit' command and result of the 'new_issue' method?

Yes, but it's the majority of the checks we do anyways.

Post by Ivan Glushkov
I've just added new action to the "act" command ("re"). So the output
of it [act command] changed. So i needed to change a lot of tests.
This difference of output would be known only to the person who made
changes in the ditrack functionality. So "commit" and "new_issue"
methods of dttest package could't guess smth if i hadn't given them
any pattern.

With the second method you'd have to update just the dttest code and not
dozens of "expected output" files all over the test subtree.

Post by Ivan Glushkov
1. Surely add some pattern outputs for typical operations to testcase repository
2. Modify 'dttest.dt' method so it'll analyze the given command and
use the appropriate pattern from test repository.
Opinions?

How is this better than what I've proposed? I'm leaning towards dttest
changes, since they are clearly visible (e.g. not wrapped into a .gz file).