Test for idlelib.HyperParser
5 lines not tested. Any suggestion on how to hit those lines welcome.
Will submit backport 2.7 once the patch for 3.4 is OK.

Which lines are not hit?

There are 7 scattered conditionals which only evaluate as one of True or False during tests and 5 lines not hit at all as a result. I am emailing instructions to install and use coverage package.

Here are details how to trigger all of the uncovered code lines and branches, listed by line.

Uncovered lines:

Line 159: This catches would-be identifiers (variable names) which are keywords or begin with a character that can't be first (e.g. a digit). We should have at least one test for each of these cases.

Lines 196-198: These strip comments from inside an expression. We should have a test with sample code with a multi-line expression with a comment inside it.

Line 225: Triggered when trying to find an expression including parentheses or brackets when they aren't closed, e.g. "[x for x in ".

Uncovered branches (except those which just cause the above):

Lines 32, 42: To trigger, have a block of code over 50 lines long and create a HyperParser at the last line (not inside any other block).

Line 236: Have a string literal inside brackets or parens, and call get_expression().

Regarding lines 32 & 42, a test could also set editwin.num_context_lines to allow triggering with smaller code blocks. It's value needs to be a list of integers, the last of which is incredibly large, perhaps sys.maxint.

Since ParenMatch and fixes* to HyperParser depend on this issue, I would like to do this first. For HyperParser.py, I would like to first commit a clean-up only patch. The test_hyperparser patch should then only add the 'if __name__' clause at the end.

I would like to apply the attached tomorrow, pending comments. It
adds docstrings and properly formats them per PEP-8; reformats comment blocks, and properly wrap lines without '\', eliminating occurences already present.

The v1 tests continue to pass once 'before the analyzed' is changed in the test file to 'precedes'. 'Index' or 'statement' might be better targets.

*After test_hyperparser.py is added, additional tests for bpo-21756 (finding closers) and new bpo-21765 -- making HyperParser work with non-ascii identifiers, will be added as part of any code fix patches.

New changeset 5063df721985 by Terry Jan Reedy in branch '2.7':
Issue bpo-21686: idlelib/HyperParser.py - Update docstrings and comments and
http://hg.python.org/cpython/rev/5063df721985

New changeset ddf15cf0db72 by Terry Jan Reedy in branch '3.4':
Issue bpo-21686: idlelib/HyperParser.py - Update docstrings and comments and
http://hg.python.org/cpython/rev/ddf15cf0db72

Coverage is now '99%'. Unless I see problems that are more than trivial, I am going to polish the patch and commit.

I believe partial coverage of "for context in editwin.num_context_lines:" is because the iterable is never empty. But it never will be in practice and I believe the code is not intended to work if it is. So I ignore this.

I believe partial coverage of deeply nested
if rawtext[pos] in "'\"":
is because this is reached with rawtext[pop] *not* in "'\"". Reading up, to reach this point, rawtext[pos] must also not be in "([":,
bracketing[brck_index][0] == brck_limit
must never become true inside the while look (because it breaks), and pos == brck_limit must be true. I don't know if this is all possible. Tal, if you find a triggering test case after I commit, it can be added later.

New changeset 59730aecce9b by Terry Jan Reedy in branch '2.7':
Issue bpo-21686: add unittest for idlelib.HyperParser. Original patch by Saimadhav
http://hg.python.org/cpython/rev/59730aecce9b

New changeset 2fc89d2230a2 by Terry Jan Reedy in branch '3.4':
Issue bpo-21686: add unittest for idlelib.HyperParser. Original patch by Saimadhav
http://hg.python.org/cpython/rev/2fc89d2230a2

Attached is the 3.4 patch as pushed. The main 'invisible' change, other than the review comment, was to create the code string just once.

I discovered that the earlier version had a bug in saying 'ok' to the 3.x HyperParser bug of no longer recognizing 'False', etc, as identifiers due to being made keywords. The buggy test properly failed on 2.7. I did the easy fix and split the bad test into two.

Since the 2.7 and 3.x versions of HyperParser were identical before the fix, the 3.x version must also not recognize the new ... Ellipsis literal. Tal, do you think doing so would be sensibly possible? (IE, would it be worth a new issue?)
...
x = ...
print(...)
are all legal 3.x expressions.

Ouch. I hadn't thought about the Ellipsis literal!

That would be sensibly possible, yes, but not simple. I think opening a separate issue for this would be prudent.

bpo-21787 Idle: make 3.x Hyperparser.get_expression recognize ...

I forgot to mention that with this particular shutdown order
@classmethod
def tearDownClass(cls):
del cls.text, cls.editwin
cls.root.destroy()
del cls.root
the shutdown warning message we have seen about not handling an event went away. Even though editwin is a dummy, it had to be deleted -- I suspect to delete its reference to the gui text widget.