What is Cynic3?
-----------------
.. image:: https://img.shields.io/pypi/v/cynic3.svg?style=flat-square
:target: https://pypi.python.org/pypi/cynic3
.. image:: https://img.shields.io/pypi/dm/cynic3.svg?style=flat-square
:target: https://pypi.python.org/pypi/cynic3
These days almost any application has several integration points
like database, payment gateway, or some Web service that it consumes
over HTTP.
All communication with the remote systems happens over the network and
both networks and those systems often go wonky.
If we do not test the behavior of **our** system when the remote end
operates out of spec and goes haywire the only place for testing
becomes in production which is, as we all know, for some systems is
less than acceptable.
Because the calls to the remote systems use network, the socket
connection can have different failure scenarios, for example:
- The remote end resets the connection by sending a TCP RST packet
- The connection may be established, but the response is never sent
back and the connection is not closed (If you don't use socket
timeouts in your app you may be in trouble at some point).
- The remote end can send garbage data as the response
- The service can send HTML over HTTP instead of the expected JSON
response
- The HTTP service can send one byte of the response data every 30
seconds
- The remote HTTP service sends only headers and no body
- The service can send megabytes of data instead of expected kilobytes
- Etc.
It would be good to be able to test the behavior of our application
when some of those conditions happen.
**cynic3** tries to help with that testing. Basically it's a test
harness (test double) that can be used to simulate crafty and devious
remote systems right from your command line.
cynic3 will try hard to cause injury to your system.
*Its goal is to make your system under test cynical.*
Read the formatted docs at `http://cynic.readthedocs.org <http://cynic.readthedocs.org>`_
**WATCH SCREENCAST** - `https://vimeo.com/43375697 <https://vimeo.com/43375697>`_
Installation
------------
::
$ [sudo] pip3 install cynic3
Or the bleeding edge version from the git master branch:
::
$ [sudo] pip3 install git+https://github.com/kudago/cynic3.git#egg=cynic3
Quick intro
-----------
Start Cynic which in turn will start multiple services on different
ports:
::
$ cynic
INFO [2012-06-03 23:44:35,603] server: Starting 'HTTPHtmlResponse' on port 2000
INFO [2012-06-03 23:44:35,603] server: Starting 'HTTPJsonResponse' on port 2001
INFO [2012-06-03 23:44:35,604] server: Starting 'HTTPNoBodyResponse' on port 2002
INFO [2012-06-03 23:44:35,604] server: Starting 'HTTPSlowResponse' on port 2003
INFO [2012-06-03 23:44:35,604] server: Starting 'RSTResponse' on port 2020
INFO [2012-06-03 23:44:35,604] server: Starting 'RandomDataResponse' on port 2021
INFO [2012-06-03 23:44:35,604] server: Starting 'NoResponse' on port 2022
INFO [2012-06-03 23:44:35,604] server: Starting 'LogRecordHandler' on port /tmp/_cynic.sock
Test different services
=======================
1. Connect to the service on port 2020 and get a TCP RST packet
right away which causes 'Connection reset by peer' message on the
command line
::
$ curl http://localhost:2020
curl: (56) Recv failure: Connection reset by peer
2. Connect to the service on port 2021 and get back 7 bytes of random data
::
$ telnet localhost 2021
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
#6
Connection closed by foreign host.
3. Connect to the service on port 2001 to get the HTTP JSON response
::
$ curl http://localhost:2001
{"message": "Hello, World!"}
So you got the basic idea. Point your application's integration points to the
Cynic's services and see how your app reacts.
Let's check out Cynic's help options
------------------------------------
::
$ cynic -h
Usage: cynic [options]
Test harness to make your system under test cynical
Options:
-h, --help show this help message and exit
-c CONFIG_PATH, --config=CONFIG_PATH
Path to an INI configuration file. If no configuration
file is provided then default configuration is
applied. To see the default configuration use -d
option described below.
-d, --dump Dump default configuration to STDOUT
As you can see if we start **Cynic** without **-c** option the default
configuration is used and **-d** is used to dump that configuration to
the standard out.
Let's see what's included in the default configuration
Default configuration
---------------------
::
$ cynic -d
############################################################
# HTTP protocol specific #
############################################################
[handler:httphtml]
# sends simple 'hello world!' HTML page over HTTP as a response
# and terminates
class = cynic.handlers.httphtml.HTTPHtmlResponse
#args = ('/tmp/test.html', )
host = 0.0.0.0
port = 2000
[handler:httpjson]
# sends simple 'hello world!' JSON over HTTP as a response
# and terminates
class = cynic.handlers.httpjson.HTTPJsonResponse
#args = ('/tmp/test.json', )
host = 0.0.0.0
port = 2001
[handler:httpnone]
# sends headers, but not the response body and terminates
class = cynic.handlers.httpnone.HTTPNoBodyResponse
host = 0.0.0.0
port = 2002
[handler:httpslow]
# sends one byte of the response every 30 seconds.
# when the data to be sent is exhausted - terminates
class = cynic.handlers.httpslow.HTTPSlowResponse
#args = ('/tmp/test.json', 'application/json', 1)
host = 0.0.0.0
port = 2003
############################################################
# Any TCP socket protocol #
############################################################
[handler:reset]
# accepts a connection, sends an RST packet right away
# and terminates
class = cynic.handlers.reset.RSTResponse
host = 0.0.0.0
port = 2020
[handler:random]
# accepts a connection, sends 7 bytes from the /dev/urandom device
# and terminates
class = cynic.handlers.rnd.RandomDataResponse
host = 0.0.0.0
port = 2021
[handler:noresp]
# accepts a connection, but doesn't send any response back.
# sleeps for 24 hours and exits
class = cynic.handlers.noresp.NoResponse
host = 0.0.0.0
port = 2022
############################################################
# System handlers used internally by the Cynic server #
############################################################
[handler:unixlog]
# a logging server that accepts connections over Unix socket
# from multiple local processes to output passed log records
class = cynic.handlers.log.LogRecordHandler
host = /tmp/_cynic.sock
port = 0
family = unix
There are basically two types of handlers:
1. The ones that deal with any TCP socket protocol
2. HTTP specific handlers
Let's have a closer look at some of them.
cynic.handlers.httpslow.HTTPSlowResponse
========================================
This handler sends one byte of the HTTP response every 30 seconds.
The config part is as follows
::
[handler:httpslow]
# sends one byte of the response every 30 seconds.
# when the data to be sent is exhausted - terminates
class = cynic.handlers.httpslow.HTTPSlowResponse
#args = ('/tmp/test.json', 'application/json', 1)
host = 0.0.0.0
port = 2003
where
*class* - a fully qualified dotted Python name of the handler class
*args* - a tuple of Python values to pass as positional arguments to the handler's constructor.
**First argument** specifies absolute path to a file to read
the data from instead of using a default data sting 'Hello, world!'
**Second argument** specifies the value of HTTP's Content-Type
response header
**Third argument** specifies time interval in seconds, default
is 30, after which additional byte is sent to the client
*host* - an IP address to bind the service to (For Unix socket it's a file path)
*port* - port to listen on (not applicable for Unix sockets)
Even with this service alone you can be creative and come up with
several test scenarios that will make the life of your system under
test quite unbearable:
1. Specify file in the *args* that contains megabytes of data and see how
your system handles such a large response
2. You can change file path and content type arguments to send HTML,
JSON, XML, Plain text, etc
3. You can send HTML data but set Content-Type header value to
*application/json*
4. You can change time interval to test your socket read timeout
expiration or lack thereof.
5. You can have all above as separate services on different ports.
Just add *[handler:httpslow1]*, *[handler:httpslow2]*, etc. sections to
the INI file and tweak the *args*.
Extending Cynic with custom handlers
------------------------------------
It's very easy to add your own handler to the Cynic.
1. To add a new TCP handler inherit from *cynic.handlers.base.BaseHandler*
and implement the *handle* method which directly interacts with a
TCP socket.
2. To add a new HTTP handler inherit from
*cynic.handlers.base.BaseHTTPHandler* and implement your custom
do_GET, do_POST, do_PUT, etc methods.
For more information about the handler see `BaseHTTPRequestHandler <http://docs.python.org/library/basehttpserver.html#BaseHTTPServer.BaseHTTPRequestHandler>`_
3. Add a section *[handler:my_new_name]* to the INI configuration file with corresponding
configuration parameters.
**XXX: Full example?**
Acknowledgments
---------------
- Many ideas are taken from `Release It! <http://pragprog.com/book/mnee/release-it>`_
License
-------
Copyright (c) 2017 Ruslan Spivak, Maxim Muzafarov, Murad Byashimov
Published under The MIT License, see LICENSE
Change History
==============
3.0 (2017-01-20)
----------------
- Py3 version
1.0 (2012-06-04)
----------------
- Public release