I've been thinking about this more and studying the code and reading some
of your initial documentation.
I often read unit tests in source code projects in the hope of finding
simple, concrete usage examples. These examples not only serve to test the
code, but also also documentation on how to use it.
For being able to see concrete inputs, the test methods of the TestTOG
class do a good job. For example:
def test_attribute(self):
contents = r"""\
open(os.devnull, "w")
"""
self.make_data(contents)
But from that I don't see what the outputs are. It doesn't show me what a
TOG object can do and what it is for. From the "Generator" in the name, I
can guess that somehow there is a generate involved, so I should be able to
look over it or create a list from it. But how is that done. I look at the
make_data method, but that doesn't clear things up for me.
Is there some code you can add which make it easy to see how things work?
Something like this for example:
next(TokenOrderGenerator.fromString(r"""open(os.devnull, "w")""")) == ???
or
list(TokenOrderGenerator.fromString(r"""open(os.devnull, "w")""")) == [???,
???, ???]
I don't know what to put in the question marks above because I still don't
understand what things tog generator instances yield.
The "fromString" is a hypothetical static factory method (
https://stackoverflow.com/questions/929021/what-are-static-factory-methods/929273)
which makes it easy to instantiate the class.
On Tue, Jan 7, 2020 at 1:32 PM Brian Theado <[email protected]> wrote:
>
>
> On Tue, Jan 7, 2020 at 5:01 AM Edward K. Ream <[email protected]> wrote:
>
>> On Sunday, December 29, 2019 at 7:19:03 PM UTC-5, btheado wrote:
>>
>> I was looking at the tests in leoAst.py in the fstringify branch and I
>>> don't find any asserts in the tests themselves.
>>>
>>
>> The tests in the TestTOG are actually extremely strong. I have just
>> added the following to the docstring for the TestTOG class:
>>
>> QQQ
>> These tests call BaseTest.make_data, which creates the two-way links
>> between tokens and the parse tree.
>>
>> The asserts in tog.sync_tokens suffice to create strong unit tests.
>> QQQ
>>
>
> I'll take your word for it as it isn't obvious to me from a glance at the
> code. I don't have a huge interest in the tokens project so I don't really
> understand where the parse tree is coming from and how it relates to the
> tokens. Maybe if I really want to understand, I can intentionally break the
> code in a few places and see how the failures work.
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/leo-editor/CAO5X8Cw0%2B9d-j5xsuMVJY%3DTSQM0UqJ0jO2BzEdo-k38kP8x5LQ%40mail.gmail.com.
