Rename locust to user

README.md

@@ -18,9 +18,9 @@
 Locust is an easy-to-use, distributed, user load testing tool. It is intended for load-testing web sites (or other systems) and
 figuring out how many concurrent users a system can handle.
 
-The idea is that during a test, a swarm of locusts will attack your website. The behavior of each locust (or test user if you will) is
-defined by you and the swarming process is monitored from a web UI in real-time. This will help you battle test and identify bottlenecks
-in your code before letting real users in.
+The idea is that during a test, a swarm of simulated users will attack your website. The behavior of each user is defined by you 
+using Python code, and the swarming process is monitored from a web UI in real-time. This will help you battle test and identify 
+bottlenecks in your code before letting real users in.
 
 Locust is completely event-based, and therefore it's possible to support thousands of concurrent users on a single machine.
 In contrast to many other event-based apps it doesn't use callbacks. Instead it uses light-weight processes, through <a href="http://www.gevent.org/">gevent</a>.
@@ -42,7 +42,7 @@ of callbacks, your code looks and behaves like normal, blocking Python code.
  Locust has a neat HTML+JS that shows all relevant test details in real-time. And since the UI is web-based, it's cross-platform and easily extendable.
 
 * **Can test any system**<br>
- Even though Locust is web-oriented, it can be used to test almost any system. Just write a client for what ever you wish to test and swarm it with locusts! It's super easy!
+ Even though Locust is web-oriented, it can be used to test almost any system. Just write a client for what ever you wish to test and swarm it with users! It's super easy!
 
 * **Hackable**<br>
  Locust is very small and very hackable and we intend to keep it that way. All heavy-lifting of evented I/O and coroutines are delegated to gevent. The brittleness of alternative testing tools was the reason we created Locust.

docs/api.rst

@@ -3,24 +3,24 @@ API
 ###
 
 
-Locust class
+User class
 ============
 
-.. autoclass:: locust.core.Locust
+.. autoclass:: locust.core.User
     :members: wait_time, tasks, weight, abstract, on_start, on_stop, wait
 
-HttpLocust class
+HttpUser class
 ================
 
-.. autoclass:: locust.core.HttpLocust
+.. autoclass:: locust.core.HttpUser
     :members: wait_time, tasks, client, abstract
 
 
 TaskSet class
 =============
 
 .. autoclass:: locust.core.TaskSet
-    :members: locust, parent, wait_time, client, tasks, interrupt, schedule_task, on_start, on_stop, wait
+    :members: user, parent, wait_time, client, tasks, interrupt, schedule_task, on_start, on_stop, wait
 
 task decorator
 ==============
@@ -31,7 +31,7 @@ SequentialTaskSet class
 =======================
 
 .. autoclass:: locust.sequential_taskset.SequentialTaskSet
-    :members: locust, parent, wait_time, client, tasks, interrupt, schedule_task, on_start, on_stop
+    :members: user, parent, wait_time, client, tasks, interrupt, schedule_task, on_start, on_stop
 
 
 .. _wait_time_functions:
@@ -107,17 +107,17 @@ The event hooks are instances of the **locust.events.EventHook** class:
     to prevent your code from breaking if new arguments are added in a future version.
 
 
-Locust Runner classes
+Runner classes
 =====================
 
-.. autoclass:: locust.runners.LocustRunner
+.. autoclass:: locust.runners.Runner
     :members: start, stop, quit, user_count
 
-.. autoclass:: locust.runners.LocalLocustRunner
+.. autoclass:: locust.runners.LocalRunner
 
-.. autoclass:: locust.runners.MasterLocustRunner
+.. autoclass:: locust.runners.MasterRunner
 
-.. autoclass:: locust.runners.WorkerLocustRunner
+.. autoclass:: locust.runners.WorkerRunner
 
 
 Web UI class

docs/changelog.rst

@@ -7,8 +7,18 @@ For full details of the Locust changelog, please see https://github.com/locustio
 1.0 (In development)
 ====================
 
-Breaking changes
-----------------
+This version contains some breaking changes.
+
+Locust class renamed to User
+----------------------------
+
+We've renamed the ``Locust`` and ``HttpLocust`` classes to ``User`` and ``HttpUser``. The ``locust`` attribute on 
+:py:class:`TaskSet <locust.core.TaskSet>` instances has been renamed to :py:attr:`user <locust.core.TaskSet.user>`.
+
+
+
+Other breaking changes
+----------------------
 
 * The option for running Locust without the Web UI has been renamed from ``--no-web`` to ``--headless``.
 * Removed ``Locust.setup``, ``Locust.teardown``, ``TaskSet.setup`` and ``TaskSet.teardown`` hooks. If you want to 

docs/extending-locust.rst

@@ -7,7 +7,7 @@ Locust comes with a number of events hooks that can be used to extend Locust in
 Event hooks live on the Environment instance under the :py:attr:`events <locust.env.Environment.events>` 
 attribute. However, since the Environment instance hasn't been created when locustfiles are imported,  
 the events object can also be accessed at the module level of the locustfile through the 
-:py:attr:`locust.events` variable.
+:py:obj:`locust.events` variable.
 
 Here's an example on how to set up an event listener::
 

docs/increase-performance.rst

@@ -7,27 +7,27 @@ Increase Locust's performance with a faster HTTP client
 Locust's default HTTP client uses `python-requests <http://www.python-requests.org/>`_. 
 The reason for this is that requests is a very well-maintained python package, that 
 provides a really nice API, that many python developers are familiar with. Therefore, 
-in many cases, we recommend that you use the default :py:class:`HttpLocust <locust.core.HttpLocust>` 
+in many cases, we recommend that you use the default :py:class:`HttpUser <locust.core.HttpUser>`
 which uses requests. However, if you're planning to run really large scale tests, 
 Locust comes with an alternative HTTP client, 
-:py:class:`FastHttpLocust <locust.contrib.fasthttp.FastHttpLocust>` which 
+:py:class:`FastHttpUser <locust.contrib.fasthttp.FastHttpUser>` which
 uses `geventhttpclient <https://github.com/gwik/geventhttpclient/>`_ instead of requests.
 This client is significantly faster, and we've seen 5x-6x performance increases for making 
 HTTP-requests. This does not necessarily mean that the number of users one can simulate 
 per CPU core will automatically increase 5x-6x, since it also depends on what else 
 the load testing script does. However, if your locust scripts are spending most of their 
-CPU time in making HTTP-requests, you are likely to see signifant performance gains.
+CPU time in making HTTP-requests, you are likely to see significant performance gains.
 
 
-How to use FastHttpLocust
+How to use FastHttpUser
 ===========================
 
-Subclass FastHttpLocust instead of HttpLocust::
+Subclass FastHttpUser instead of HttpUser::
 
     from locust import task, between
-    from locust.contrib.fasthttp import FastHttpLocust
+    from locust.contrib.fasthttp import FastHttpUser
 
-    class MyLocust(FastHttpLocust):
+    class MyUser(FastHttpUser):
         wait_time = between(1, 60)
 
         @task
@@ -37,19 +37,19 @@ Subclass FastHttpLocust instead of HttpLocust::
 
 .. note::
 
-    FastHttpLocust uses a whole other HTTP client implementation, with a different API, compared to 
-    the default HttpLocust that uses python-requests. Therefore FastHttpLocust might not work as a 
-    drop-in replacement for HttpLocust, depending on how the HttpClient is used.
+    FastHttpUser uses a whole other HTTP client implementation, with a different API, compared to
+    the default HttpUser that uses python-requests. Therefore FastHttpUser might not work as a
+    drop-in replacement for HttpUser, depending on how the HttpClient is used.
 
 
 API
 ===
 
 
-FastHttpLocust class
+FastHttpUser class
 --------------------
 
-.. autoclass:: locust.contrib.fasthttp.FastHttpLocust
+.. autoclass:: locust.contrib.fasthttp.FastHttpUser
     :members: network_timeout, connection_timeout, max_redirects, max_retries, insecure
 
 

docs/quickstart.rst

@@ -21,9 +21,9 @@ Below is a quick little example of a simple **locustfile.py**:
 .. code-block:: python
 
     import random
-    from locust import HttpLocust, task, between
+    from locust import HttpUser, task, between
 
-    class WebsiteUser(HttpLocust):
+    class WebsiteUser(HttpUser):
         wait_time = between(5, 9)
 
         @task(2)
@@ -37,7 +37,7 @@ Below is a quick little example of a simple **locustfile.py**:
             self.client.get("/post?id=%i" % post_id, name="/post?id=[post-id]")
 
         def on_start(self):
-            """ on_start is called when a Locust start before any task is scheduled """
+            """ on_start is called when a User starts before any task is scheduled """
             self.login()
 
         def login(self):
@@ -49,10 +49,10 @@ Let's break it down:
 
 .. code-block:: python
 
-    class WebsiteUser(HttpLocust):
+    class WebsiteUser(HttpUser):
 
 Here we define a class for the users that we will be simulating. It inherits from 
-:py:class:`HttpLocust <locust.core.HttpLocust>` which gives each user a ``client`` attribute, 
+:py:class:`HttpUser <locust.core.HttpUser>` which gives each user a ``client`` attribute,
 which is an instance of :py:class:`HttpSession <locust.clients.HttpSession>`, that 
 can be used to make HTTP requests to the target system that we want to load test. When a test starts, 
 locust will create an instance of this class for every user that it simulates, and each of these 

docs/running-locust-distributed.rst

@@ -22,11 +22,11 @@ processor core** on the worker machines.
 
 .. note::
     It's recommended that you start a number of simulated users that are greater  than 
-    ``number of locust classes * number of workers`` when running Locust distributed.
+    ``number of user classes * number of workers`` when running Locust distributed.
 
     Otherwise - due to the current implementation - 
-    you might end up with a distribution of the  Locust classes that doesn't correspond to the 
-    Locust classes' ``weight`` attribute. And if the hatch rate is lower than the number of worker
+    you might end up with a distribution of the  User classes that doesn't correspond to the
+    User classes' ``weight`` attribute. And if the hatch rate is lower than the number of worker
     nodes, the hatching would occur in "bursts" where all worker node would hatch a single user and
     then sleep for multiple seconds, hatch another user, sleep and repeat.
 

docs/running-locust-in-step-load-mode.rst

@@ -39,7 +39,7 @@ If you want to run Locust in step load mode without the web UI, you can do that
 
 .. code-block:: console
 
-    $ locust -f --headless -c 1000 -r 100 --run-time 1h30m --step-load --step-clients 300 --step-time 20m
+    $ locust -f --headless -u 1000 -r 100 --run-time 1h30m --step-load --step-clients 300 --step-time 20m
 
 Locust will swarm the clients by step and shutdown once the time is up.
 

docs/running-locust-without-web-ui.rst

@@ -5,13 +5,13 @@ Running Locust without the web UI
 =================================
 
 You can run locust without the web UI - for example if you want to run it in some automated flow, 
-like a CI server - by using the ``--headless`` flag together with ``-c`` and ``-r``:
+like a CI server - by using the ``--headless`` flag together with ``-u`` and ``-r``:
 
 .. code-block:: console
 
-    $ locust -f locust_files/my_locust_file.py --headless -c 1000 -r 100
+    $ locust -f locust_files/my_locust_file.py --headless -u 1000 -r 100
 
-``-c`` specifies the number of Locust users to spawn, and ``-r`` specifies the hatch rate 
+``-u`` specifies the number of Users to spawn, and ``-r`` specifies the hatch rate
 (number of users to spawn per second).
 
 
@@ -22,7 +22,7 @@ If you want to specify the run time for a test, you can do that with ``--run-tim
 
 .. code-block:: console
 
-    $ locust -f --headless -c 1000 -r 100 --run-time 1h30m
+    $ locust -f --headless -u 1000 -r 100 --run-time 1h30m
 
 Locust will shutdown once the time is up.
 
@@ -33,7 +33,7 @@ By default, locust will stop your tasks immediately. If you want to allow your t
 
 .. code-block:: console
 
-    $ locust -f --headless -c 1000 -r 100 --run-time 1h30m --stop-timeout 99
+    $ locust -f --headless -u 1000 -r 100 --run-time 1h30m --stop-timeout 99
 
 .. _running-locust-distributed-without-web-ui:
 

docs/testing-other-systems.rst

@@ -7,19 +7,19 @@ any request/response based system, by writing a custom client that triggers
 :py:attr:`request_success <locust.event.Events.request_success>` and 
 :py:attr:`request_failure <locust.event.Events.request_failure>` events.
 
-Sample XML-RPC Locust client
+Sample XML-RPC User client
 ============================
 
-Here is an example of a Locust class, **XmlRpcLocust**, which provides an XML-RPC client, 
-**XmlRpcClient**, and tracks all requests made:
+Here is an example of a User class, **XmlRpcUser**, which provides an XML-RPC client,
+**XmlRpcUser**, and tracks all requests made:
 
 .. literalinclude:: ../examples/custom_xmlrpc_client/xmlrpc_locustfile.py
 
 If you've written Locust tests before, you'll recognize the class called ``ApiUser`` which is a normal 
-Locust class that has a couple of tasks declared. However, the ``ApiUser`` inherits from 
-``XmlRpcLocust`` that you can see right above ``ApiUser``. The ``XmlRpcLocust`` is marked as abstract 
+User class that has a couple of tasks declared. However, the ``ApiUser`` inherits from
+``XmlRpcUser`` that you can see right above ``ApiUser``. The ``XmlRpcUser`` is marked as abstract
 using ``abstract = True`` which means that Locust till not try to create simulated users from that class 
-(only of classes that extends it). ``XmlRpcLocust`` provides an instance of XmlRpcClient under the 
+(only of classes that extends it). ``XmlRpcUser`` provides an instance of XmlRpcClient under the
 ``client`` attribute. 
 
 The ``XmlRpcClient`` is a wrapper around the standard 

docs/third-party-tools.rst

@@ -18,8 +18,8 @@ Using other languages
 =====================
 
 A Locust master and a Locust worker communicate by exchanging `msgpack <http://msgpack.org/>`_ messages, which is
-supported by many languages. So, you can write your Locust tasks in any languages you like. For convenience, some
-libraries do the job as a worker runner. They run your Locust tasks, and report to master regularly.
+supported by many languages. So, you can write your User tasks in any languages you like. For convenience, some
+libraries do the job as a worker runner. They run your User tasks, and report to master regularly.
 
 
 Golang

docs/use-as-lib.rst

@@ -10,13 +10,13 @@ To run Locust as a library you need to create an :py:class:`Environment <locust.
 
     from locust.env import Environment
 
-    env = Environment(locust_classes=[MyTestUser])
+    env = Environment(user_classes=[MyTestUser])
 
 The :py:class:`Environment <locust.env.Environment>` instance's 
 :py:meth:`create_local_runner <locust.env.Environment.create_local_runner>`, 
 :py:meth:`create_master_runner <locust.env.Environment.create_master_runner>` or 
-:py:meth:`create_worker_runner <locust.env.Environment.create_worker_runner> can then be used to start a 
-:py:class:`LocustRunner <locust.runners.LocustRunner>` instance, which can be used to start a load test:
+:py:meth:`create_worker_runner <locust.env.Environment.create_worker_runner>` can then be used to start a 
+:py:class:`Runner <locust.runners.Runner>` instance, which can be used to start a load test:
 
 .. code-block:: python
 

docs/what-is-locust.rst

@@ -5,11 +5,10 @@ What is Locust?
 Locust is an easy-to-use, distributed, user load testing tool. It is intended for load-testing web sites
 (or other systems) and figuring out how many concurrent users a system can handle.
 
-The idea is that during a test, a swarm of `locusts <http://en.wikipedia.org/wiki/Locust>`_ 
-will attack your website. The behavior of each 
-locust (or test user if you will) is defined by you and the swarming process is monitored from a 
-web UI in real-time. This will help you battle test and identify bottlenecks in your code before 
-letting real users in.
+The idea is that during a test, a swarm of `locust <http://en.wikipedia.org/wiki/Locust>`_ users
+will attack your website. The behavior of each user is defined by you using Python code, and the 
+swarming process is monitored from a web UI in real-time. This will help you battle test and identify 
+bottlenecks in your code before letting real users in.
 
 Locust is completely event-based, and therefore it's possible to support thousands of concurrent
 users on a single machine. In contrast to many other event-based apps it doesn't use callbacks.