[ditrack commit] r2398 - issues/data/i188

[Vlad Skvortsov]

Ivan Glushkov wrote:
>> 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.

> 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.

> 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?
>   

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).

-- 
Vlad Skvortsov, vss at 73rus.com, http://vss.73rus.com