On Mon, Jul 30, 2018 at 2:50 PM, vitalije wrote:
During the last two weeks I have felt at times being very stupid or more
> precisely doing stupid and unnecessary work. The only way I could force
> myself to continue this work is by telling myself over and over again that
> this is just something that I might do as an exercise in some other
> circumstances.
>
Making unit tests pass is never stupid or unnecessary. For example, it was
essential in the development of the curses gui.
> Leo unit tests are executed with NullGui. And it means that I had to write
> NullGui version of NewTreeWidget just to make it pass all the tests. That
> made me think more about what we are doing with this unit testing scheme.
> There is no other reason for this class to exists. The only purpose is to
> make unit tests pass. But that means those unit tests won't test
> NewTreeWidget at all! In fact I could make those tests pass even if I
> completely delete NewTreeWidget class. Leo would not be able to start but,
> unit tests will pass.
>
All true, but this is not the whole story. TestManager.doTests runs tests
with a Null gui, but changing a single switch will run all tests with the
present gui. It would be straightforward to have doTests use other guis or
widgets.
Furthermore, the NullGui class could be called documentation. It shows the
minimal needed to interact with Leo's core.
I think that there are quite a few tests that are testing wrong things
> (IMHO). For example there are few tests that are testing that Cut, Copy and
> Paste work correctly in text line editor for editing headlines. We should
> trust GUI frameworks to do their job.
>
Handling text in Qt headline (QLineEdit) widgets is more than tricky. It's
horrible. The unit tests aren't testing the Qt code, they are testing the
extremely fragile code that interfaces with Qt.
Perhaps some of these difficulties would go away in your code. It would be
great if headline widgets were never deallocated. But they are, at
present, whenever the screen is redrawn.
What we need to test in this case is that if this widget emits some
> signal/notification, that its content has been changed, our headline must
> change accordingly. It is not necessary to test that this widget performs
> clipboard operations correctly.
>
I disagree, as I have just explained.
I don’t see any signal/notification code in nullGui text widget. That means
> our unit tests are checking how StringTextWrapper performs text
> manipulation.
>
Correct.
If it doesn’t emit any signal when its content change then all that unit
> tests do is to call the methods on this object like: insert, delete,
> append, copy, paste, move cursor around and then check that content and its
> selection indexes are correct. No check is made to prove that by editing
> this widget anything should happen elsewhere in Leo. It seems that lots of
> unit tests are just proving that null gui is correctly implemented. No
> guarantees that Leo works as expected.
>
I think of unit tests as a form of double entry book keeping. Yes, some
tests, in some contexts, could be considered redundant, but that redundancy
would be useful whenever various assumptions changed. And the best example
of a big change in assumption is when implementing a new gui, or a new
widget.
Yes, we can deduce from these tests that if real GUI widgets have methods
> that work exactly like the methods of StringTextWrapper, then all commands
> that call these methods in particular order and with particular arguments
> will produce the same result. So that can be taken as a proof that methods
> implementing some gui commands work correctly. But if that is what we
> wanted to prove, wouldn’t be easier and cleaner to test just that?
>
Redundancy is our friend. It tests various aspects of things in ways that
*should* be equivalent, but sometimes aren't. It's no burden to run
"redundant" unit tests, provided they pass.
> Function implementing gui command takes as input text and selection as
> arguments and provides text and selection as a result. If it gives expected
> results it wouldn’t matter if this function is called to operate on the
> arguments taken from a real gui widget or not.
>
F
eel free to use this pattern in new unit tests.
Somehow unit tests give a false impression that they are testing gui when
> in fact all that they test are methods which implement gui commands. And
> they test it on most strange way by creating false widgets to operate on
> them when in fact all that matters are their input arguments and their
> output.
>
I'm pretty happy with the present tests. Their great virtue is that they
are extremely fast.
Some of them might be called integration tests, rather than unit tests.
To test gui (as I understand it) is to test that everything is wired
> correctly. When user changes text in body it should change b property of
> selected position/vnode. If model changes it should change body text and
> should not update model
