Blob Blame History Raw
--- TestSlide-2.6.4/docs/strict_mock/index.rst.no_ipython	2020-12-31 08:48:17.000000000 -0800
+++ TestSlide-2.6.4/docs/strict_mock/index.rst	2021-01-14 18:04:09.236997463 -0800
@@ -16,7 +16,7 @@
 
 Let's pretend we depend on a ``Calculator`` class and we want to create a mock for it:
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [1]: from unittest.mock import Mock
 
@@ -53,7 +53,7 @@
 
 ``StrictMock`` allows you to create **mocks of instances of a given template class**. Its default is **not** to give arbitrary canned responses, but rather be clear that it is missing some configuration:
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [1]: from testslide import StrictMock
 
@@ -71,7 +71,7 @@
 
 So, let's define ``is_odd`` method:
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [5]: mock.is_odd = lambda number: False
 
@@ -90,7 +90,7 @@
 
 Any magic methods defined at the template class will also have the safe by default characteristic:
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [1]: from testslide import StrictMock
 
@@ -111,7 +111,7 @@
 
 You won't be allowed to set an attribute to a ``StrictMock`` if the given template class does not have it:
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [1]: from testslide import StrictMock
 
@@ -137,7 +137,7 @@
 
 This validation works even for attributes set by ``__init__``, as ``StrictMock`` introspects the code to learn about them:
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [1]: from testslide import StrictMock
      ...:
@@ -156,7 +156,7 @@
 
 When type annotation is available for attributes, ``StrictMock`` won't allow setting it with an invalid type:
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [1]: import testslide
 
@@ -177,7 +177,7 @@
 
 Method signatures must match the signature of the equivalent method at the template class:
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [1]: from testslide import StrictMock
 
@@ -199,7 +199,7 @@
 
 Methods with type annotation will have call arguments validated against it and invalid types will raise:
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [1]: import testslide
 
@@ -225,7 +225,7 @@
 
 Methods with return type annotated will have its return value type validated as well:
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [1]: import testslide
 
@@ -245,7 +245,7 @@
 
 If the Template class attribute is a instance/class/static method, ``StrictMock`` will only allow callable values to be assigned:
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [1]: from testslide import StrictMock
 
@@ -266,7 +266,7 @@
 
 Coroutine functions (``async def``) (whether instance, class or static methods) can only have a callable that returns an awaitable assigned:
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [1]: from testslide import StrictMock
 
@@ -298,7 +298,7 @@
 
 You can optionally name your mock, to make it easier to identify:
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [1]: from testslide import StrictMock
 
@@ -313,7 +313,7 @@
 
 By giving a template class, we can leverage all interface validation goodies:
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [1]: from testslide import StrictMock
 
@@ -334,7 +334,7 @@
 
 It is higly recommended to use ``StrictMock`` giving it a template class, so you can leverage its interface validation. There are situations however that any "generic mock" is good enough. You can still use StrictMock, although you'll loose most validations:
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [1]: from testslide import StrictMock
 
@@ -357,7 +357,7 @@
 
 They can be set as usual:
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [1]: from testslide import StrictMock
 
@@ -380,7 +380,7 @@
 
 You can assign callables to instance, class and static methods as usual. There's special mechanics under the hood to ensure the mock will receive the correct arguments:
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [1]: from testslide import StrictMock
      ...:
@@ -424,7 +424,7 @@
 
 You can also use regular methods:
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [11]: def new(message):
       ...:     return f"new {message}"
@@ -437,7 +437,7 @@
 
 Or even methods from any instances:
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [14]: class MockEcho:
       ...:     def echo(self, message):
@@ -454,7 +454,7 @@
 
 Magic Methods must be defined at the instance's class and not the instance. ``StrictMock`` has special mechanics that allow you to set them **per instance** trivially:
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [1]: from testslide import StrictMock
 
@@ -479,7 +479,7 @@
 
 If the template class is a context manager, ``default_context_manager`` can be used to automatically setup ``__enter__`` and ``__exit__`` mocks for you:
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [1]: from testslide import StrictMock
 
@@ -508,7 +508,7 @@
 
 By default, ``StrictMock`` will validate arguments passed to callable attributes and the return value when called. This is done by inserting a proxy object in between the attribute and the value. In some rare situations, this proxy object can cause issues (eg if you ``assert type(self.attr) == Foo``). If having ``type()`` return the correct value is more important than having API validation, you can disable them:
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [1]: from testslide import StrictMock
 
@@ -538,13 +538,13 @@
 
 If this type validation yields bad results (likely a bug, please report it), you can disable it with:
 
-.. code-block:: ipython
+.. code-block:: python
 
   StrictMock(template=SomeClass, type_validation=False)
 
 If you don't want to disable type validation for the entire ``StrictMock``, just for specific attributes, pass ``attributes_to_skip_type_validation`` to the constructor of ``StrictMock``
 
-.. code-block:: ipython
+.. code-block:: python
 
   In [1]: from testslide import StrictMock