The attached patch works on 3.3 and just need a small addition for 100$ coverage. After that, I intend to commit after porting to 2.7 (only two lines to change, I think) and testing it there.

I split the search test case into three, one for each method. The tests for search_text repeated the tests for search_forward/backward. Simple mocks for the latter two allow to test for what search_text actually does: pick the right function to call and right starting point.

The effect of the ok parameter is complicated because it has different effects in search_text and the other two (and less effect in search_backward than in search_forward because they are not symmetric).

'\w+' never matches an empty string; so there was no test of 'ok=true' in search_forward. '\w*' can have empty matches and there now is a test. I discovered what seems to me a bug. If an initial null match is ignored, the search skips the rest of the line and skips to the next. This seems wrong but I am not sure what the proper behavior should be. I want to investigate the use of ok in the dialogs, especially the replace dialog before deciding

The test of search_forward uses the mock Text. The remaining gui uses here (and many in other tests) could be eliminated with just a partial implementation of marks and selections, one that kept them fixed rather than moving them with insert and delete. So far we have been inserting text just once and then setting and getting things on a fixed text.