Add a section to the installation docs about running tests

[matthiask]

Fixes #1920.

I thought about including the relevant documentation in the earlier steps, but I'd have to explain DEBUG, INTERNAL_IPS and TESTING all at once instead of introducing everything step by step. So even though it may be annoying to go back and modify code the user just added it still reads better to me, especially since it only applies to users running tests in their project. (I would hope a lot of them do, but still.)

Checklist:

• I have added the relevant tests for this change.
• I have added an item to the Pending section of docs/changes.rst.

[tim-schilling]

I don't think this was necessary. The docs point the user to the example app in the repo.

[tim-schilling]

Check out the configuration example in the example app to learn how to set up the toolbar to function smoothly while running your tests.

[matthiask]

I'm not so sure. The example contains many aspects and the test suite thing is just one of them. The question arrived really quickly and I thought I'd lean towards more docs. Maybe the section could be shortened somewhat or people could be made aware of the problem in ways which are shorter than the current version but maybe still more visible than what we had before?

[tim-schilling]

I feel like there's a better installation process with AppConfig.ready and the middleware where we could check DEBUG after the Django test runner does its magic.

[matthiask]

Definitely sounds interesting. One of my first big(ger) decisions in this project was to remove the magical installation, so I'm a bit wary, but AppConfig.ready sounds like a good way to opt into some behaviors.

[tim-schilling]

Ah we may have a difference of opinion then. I feel like asking a person to add any if statements to their apps configuration is a shortcoming of the project.

[matthiask]

Yes, maybe :-)

I lean towards the "worse is better" school of software design where it's slightly better to be simple than to be correct. I think that everything breaks down at a point, and if the implementation is simple it will be easier to understand and fix (or work around) than if the implementation is complex.

That being said, I like Django a lot and its implementation certainly isn't simple. So it really depends. As long as we can put behaviors into parts which can be easily replaced and which have a small API I'm fine with it. The show_toolbar(request) -> bool callback is a great example of this.

Also, I won't stand in the way since it's not my personal project after all!