This article explores the issue of running “simultaneous” searches for all entries in a list of terms (in reality, we are running searches asynchronously).
I’m also trying to improve on Azure’s Search API example a bit.
This article attempts to explain how to setup your Django project so you can leverage GitLab.com’s free Continuous Integration features - available on their hosted environment, for their free account tier, on top of unlimited private repositories!
The TLDR version is:
You push your changes to a remote “dev” branch and GitLab will:
This is probably the simplest/fastest way to integrate BrowserSync with your Django development workflow, allowing a few cool thinks to happen automatically:
Browser reloads whenever you edit your code (no more CTRL+R or F5);
Sync your view across multiple browsers and devices, so you can see how changes are displayed in different platforms/window sizes;
Interactions on one device are also synced, any scrolling or typing in one window is simultaneously reflected in the other ones;
Some frameworks allow you to test your controllers directly - usually a faster approach to using Selenium and headless browsers.
I decided to try that for a new FW/1 app, but since I could only find discussions on how to do that, and not a lot of code, I decided to try that on my own, using TestBox.
This picks up where my FW/1 Example Application Articles left… I suggest you read that in case any of the code seems confusing.
This article is similar to the Ready to use Structure for Django Tests and the main goals are:
We’ll use my Flask App to generate summaries as the test target (feel free to clone it).
Note: This article was updated on JAN-2019 to reflect changes in the original project (a section on API testing was added).
This article builds up on the Structure for Django Tests and shows how you can easily display individual running times for each test in a group or suite - and you can use in Flask tests too! - check out my Flask App to generate summaries.
This article proposes a flexible and efficient test structure, so readers don’t have to go through the many Django testing resources available online before getting started.
This structure allows developers to:
Organize and group different test types (unit, integration, functional tests, etc…).
Run tests individually, or by group, or all of them.
Define logic that is common to all tests (e.g. client login/logout, utility functions)
Populate your test database programmatically.