Would it be feasible to collect enough data from an installation to
replicate the user's environment?

A "leo.state" file would contain settings, plugins, versions.
It could be used to install on a VM, or maybe parsed for known issues.

On Thu, Oct 20, 2011 at 12:32 PM, Edward K. Ream <[email protected]> wrote:
>
>
> On Oct 17, 2:41 pm, Kent Tenney <[email protected]> wrote:
>> As I understand the discipline expected in the Zope community:
>>
>> When approaching a bug, begin by writing a test which fails
>> due to the bug. Then fix the code such that the test succeeds.
>>
>> Patches which don't follow this convention are not considered.
>> (code without tests is assumed buggy)
>
> I have been thinking about this comment ever since, especially as I
> fix bugs, or attempt to fix bugs, without unit tests :-)
>
> The problem, as I see it now, is that it is, at present, impossible to
> run most unit tests in the environment in which the bugs actually
> appear.  This can take several forms:
>
> 1.  In the latest instance, there would have been no way to replicate
> the bug because the bug had already been fixed.  This is just
> infuriating.  Happily, this situation has been rare.
>
> 2. Many (most?) bugs nowadays depend on a specific set of plugins
> being enabled, or a specific set of options being in effect.   But I
> run unit tests from a *particular* script, that runs unitTest.leo with
> a *particular* set of options.  Furthermore, running tests externally
> is *more* restrictive, not less, because at present running tests
> externally uses the leoBridge module, which in turn uses the nullGui.
>
> 3. Gui-related bugs cause particular problems for unitTest.leo,
> because I don't like to pollute the output with the output from
> various work-arounds to code that would otherwise put up dialogs and
> thus pause the unit tests.
>
> In other words, gui-related unit tests often result in added code (in
> the code being tested) that a) are almost pure cruft and b) typically
> actively subvert the intention of the actual test!  This does not seem
> like progress: I would (usually) prefer to endure repeated (failed)
> attempts to fix the bug rather than pollute the code.
>
> In short, a more general testing framework is needed.  Until that
> happens, we will have to muddle through with untested, and thus very-
> likely buggy code.
>
> Edward
>
> --
> You received this message because you are subscribed to the Google Groups 
> "leo-editor" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group at 
> http://groups.google.com/group/leo-editor?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Reply via email to