Slow update times during unit testing

[RobinRamael]

Hey,

Thanks for the project, we've been using it here for 2 mid-sized projects and it's been working out pretty well.

I'm currently moving a project from haystack to bungiesearch and have noticed that the way we're rebuilding the index from scratch when running unittests is several orders of magnitude slower than the haystack stuff, even though there's only a small number of objects being indexed. This is how we have it now:

class SearchTestCase(TestCase):
    ...
    def _update_index(self):
        call_command('search_index', action='delete', confirmed=True, interactive=False)
        with self.assertRaises(elasticsearch.TransportError):
            call_command('search_index', action='create')
        call_command('search_index', action='update')

_update_index is then called whenever we need it, mostly after filling up the test db. We need to catch the transport error because of timeouts (status never goes to green, but this doesn't seem to affect anything). My guess is that bungie waits for the green, hits the timeout and continues.

Is there a recommended way to do this, maybe without the inelegant call_command calls?

[ChristopherRabotin]

Interesting case. In the past, I've used this only with a persistent test database that had almost all the data from the real database. The ES instance was tied to the real database, and we ran our tests on that.

• Would it be possible to just have an ES instance that you turn on right before the test, and turn off afterward?
• If you specifically need to catch timeout issues, maybe a simpler (but not great) way is to duplicate the code from the command into your tests: https://github.com/ChristopherRabotin/bungiesearch/blob/master/bungiesearch/management/commands/search_index.py#L163 .

[RobinRamael]

I'll look into it. We use factories (factory-boy) to set up our test data. It might be interesting to provide the possibility of defining a test inde like django does it with databases when testing.