On Sunday, September 1, 2019 at 12:46:51 PM UTC-5, Edward K. Ream wrote:
Some second thoughts. We have drastically changed mind sets. In my
previous thinking, everything was dangerous. In the context of the new
testing script, everything is allowed.
The overall goal is to know where we have been and where we are going. In
this new world, *there are no strict rules*. The following aren't even
suggestions. They are just new possibilities that have appeared...
I am not sure what you mean by unit test, but here is how I see it.
>>
>
> In this context, a unit test is simply a script that verifies, in some
> unspecified way, that exiting code works. It can also be applied to any
> proposed refactoring/simplification of the code.
>
Still true :-)
To do both, the unit test should be self contained. That is, it should not
> use existing code, but instead work from "first principles", that is, the
> highest-possible description of what is intended. I think of such tests as
> a form of double-entry bookkeeping.
>
Let me modify and extend this statement in several ways:
First principles are indeed an important guide. Leo's documentation might
suggest new tests.
Having said that, testing scripts should be allowed to "peek" into Leo's
internals, both to verify what the existing state of affairs is, and to
re-verify what new code does. The "peeks" can be different in each case.
We probably do want to *start* by using only Leo's api. In this case,
c.config.get* is a primary resource. However, we should feel free to *add*
to Leo's api, to make testing easier.
I'll soon add an "official" method, say,
c.config.getSource(aGeneralSetting). aGeneralSetting will be a
g.GeneralSetting, returned by c.config.get*. c.config.getSource will
return a string, one of ('leoSettings', 'myLeoSettings', 'theme', 'local',
'unknown', 'error').
The script complements Leo's existing unit tests. In my mind, the script
> should be substantially more ambitious. It should test, as much as
> possible, all of Leo's settings, verifying that settings work as expected
> no matter where they are defined. This kind of test might take minutes.
>
Nah, it shouldn't take minutes. Tests should just verify the basics:
1. They should verify the basic settings precedence:
- Settings in local files override all other settings.
- Settings in theme files override settings in myLeoSettings.leo and
leoSettings.leo.
- Settings in myLeoSettings.leo override settings in leoSettings.leo.
2. Tests would also verify basic stuff like:
- That all of the basic settings nodes (@bool, @string, @int, etc) work as
expected.
- That the global, special case nodes (@button, @command, @enabled-plugins)
work as expected.
3. (Very important) that *loading a new local file works as expected*.
Ditto for theme files.
All these tests will likely be clearer and faster if they are applied to
smallish versions of local files, theme files, myLeoSettings.leo and
leoSettings.leo. For testing, we could even modify the search order so that
testing files are found first.
*Summary*
We are free to do virtually anything in the new testing framework. There
are no strict rules.
The overall goal is to know where we are, and where any new code takes us.
A thorough testing framework may reveal edge cases in the existing code,
that would be difficult, or foolish, to duplicate in proposed new code.
I'm not ruling out changing such edge cases, provided we do so consciously,
and document what we have done.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/leo-editor/58125997-0284-429c-8d6d-7c4fd44c2adb%40googlegroups.com.
