From a4e499a5433296de9f51728f5e13adc197836dad Mon Sep 17 00:00:00 2001 From: Tim Abbott Date: Fri, 18 Sep 2020 16:39:07 -0700 Subject: [PATCH] docs: Adjust spelling s/back end/backend/. --- docs/testing/testing-with-django.md | 12 ++++++------ docs/tutorials/new-feature-tutorial.md | 2 +- frontend_tests/node_tests/filter.js | 2 +- static/js/muting_ui.js | 4 ++-- static/js/settings_bots.js | 2 +- 5 files changed, 11 insertions(+), 11 deletions(-) diff --git a/docs/testing/testing-with-django.md b/docs/testing/testing-with-django.md index 220f53cf50..cb6d977b1a 100644 --- a/docs/testing/testing-with-django.md +++ b/docs/testing/testing-with-django.md @@ -2,7 +2,7 @@ ## Overview -Zulip uses the Django framework for its Python back end. We +Zulip uses the Django framework for its Python backend. We use the testing framework from [django.test](https://docs.djangoproject.com/en/1.10/topics/testing/) to test our code. We have over a thousand automated tests that verify that @@ -17,7 +17,7 @@ the design of our software. If you have worked on other Django projects that use unit testing, you will probably find familiar patterns in Zulip's code. This document -describes how to write tests for the Zulip back end, with a particular +describes how to write tests for the Zulip backend, with a particular emphasis on areas where we have either wrapped Django's test framework or just done things that are kind of unique in Zulip. @@ -374,7 +374,7 @@ A detailed description of mocks, along with useful coded snippets, can be found ### Template tests In [zerver/tests/test_templates.py](https://github.com/zulip/zulip/blob/master/zerver/tests/test_templates.py) -we have a test that renders all of our back end templates with +we have a test that renders all of our backend templates with a "dummy" context, to make sure the templates don't have obvious errors. (These tests won't catch all types of errors; they are just a first line of defense.) @@ -382,20 +382,20 @@ just a first line of defense.) ### SQL performance tests A common class of bug with Django systems is to handle bulk data in -an inefficient way, where the back end populates objects for join tables +an inefficient way, where the backend populates objects for join tables with a series of individual queries that give O(N) latency. (The remedy is often just to call `select_related()`, but sometimes it requires a more subtle restructuring of the code.) We try to prevent these bugs in our tests by using a context manager called `queries_captured()` that captures the SQL queries used by -the back end during a particular operation. We make assertions about +the backend during a particular operation. We make assertions about those queries, often simply asserting that the number of queries is below some threshold. ### Event-based tests -The Zulip back end has a mechanism where it will fetch initial data +The Zulip backend has a mechanism where it will fetch initial data for a client from the database, and then it will subsequently apply some queued up events to that data to the data structure before notifying the client. The `BaseAction.do_test()` helper helps tests diff --git a/docs/tutorials/new-feature-tutorial.md b/docs/tutorials/new-feature-tutorial.md index 5163def479..001e5e2b52 100644 --- a/docs/tutorials/new-feature-tutorial.md +++ b/docs/tutorials/new-feature-tutorial.md @@ -484,7 +484,7 @@ documentation to learn more about the backend testing framework. ### Update the frontend -After completing the process of adding a new feature on the back end, +After completing the process of adding a new feature on the backend, you should make the required frontend changes: in this case, a checkbox needs to be added to the admin page (and its value added to the data sent back to server when a realm is updated) and the change event needs to be diff --git a/frontend_tests/node_tests/filter.js b/frontend_tests/node_tests/filter.js index f2fd81a98c..2cc26ce623 100644 --- a/frontend_tests/node_tests/filter.js +++ b/frontend_tests/node_tests/filter.js @@ -104,7 +104,7 @@ run_test("basics", () => { assert(!filter.is_personal_filter()); // Negated searches are just like positive searches for our purposes, since - // the search logic happens on the back end and we need to have can_apply_locally() + // the search logic happens on the backend and we need to have can_apply_locally() // be false, and we want "Search results" in the tab bar. operators = [{operator: "search", operand: "stop_word", negated: true}]; filter = new Filter(operators); diff --git a/static/js/muting_ui.js b/static/js/muting_ui.js index a625878736..2be325b321 100644 --- a/static/js/muting_ui.js +++ b/static/js/muting_ui.js @@ -11,8 +11,8 @@ let last_topic_update = 0; exports.rerender = function () { // Note: We tend to optimistically rerender muting preferences before - // the back end actually acknowledges the mute. This gives a more - // immediate feel to the user, and if the back end fails temporarily, + // the backend actually acknowledges the mute. This gives a more + // immediate feel to the user, and if the backend fails temporarily, // re-doing a mute or unmute is a pretty recoverable thing. stream_list.update_streams_sidebar(); diff --git a/static/js/settings_bots.js b/static/js/settings_bots.js index 276fa395eb..814accab0a 100644 --- a/static/js/settings_bots.js +++ b/static/js/settings_bots.js @@ -516,7 +516,7 @@ exports.set_up = function () { avatar_widget.clear(); typeahead_helper.clear_rendered_person(bot_id); if (data.avatar_url) { - // Note that the avatar_url won't actually change on the back end + // Note that the avatar_url won't actually change on the backend // when the user had a previous uploaded avatar. Only the content // changes, so we version it to get an uncached copy. image_version += 1;