stackinabox 0.13

Error Codes

StackInABox has some specific error codes to help with diagnosing issues:

• 597 - StackInABox - Base URL is correct, but service is unknown

• 596 - StackInABox - Handling StackInABoxService generated an exception

• 595 - StackInABoxService - Route Not handled

Both of these are extremely easy to use as shown in the following examples:

HTTPretty

httypretty works well with class-based tests.

import unittest

import httpretty
import requests

import stackinabox.util.httpretty
from stackinabox.stack import StackInABox
from stackinabox.services.hello import HelloService


@httpretty.activate
class TestHttpretty(unittest.TestCase):

    def setUp(self):
        super(TestHttpretty, self).setUp()
        StackInABox.register_service(HelloService())

    def tearDown(self):
        super(TestHttpretty, self).tearDown()
        StackInABox.reset_services()

    def test_basic(self):
        stackinabox.util.httpretty.httpretty_registration('localhost')

        res = requests.get('http://localhost/')
        self.assertEqual(res.status_code, 200)
        self.assertEqual(res.text, 'Hello')

There is now also the option of using a decorator:

import unittest

import requests

import stackinabox.util.httpretty.decorator as stack_decorator
from stackinabox.services.hello import HelloService


class TestHttpretty(unittest.TestCase):

    @stack_decorator.stack_activate('localhost', HelloService())
    def test_basic(self):
        res = requests.get('http://localhost/')
        self.assertEqual(res.status_code, 200)
        self.assertEqual(res.text, 'Hello')

Responses

responses works well with function-based tests; however, it does require you use the Python requests library.

import unittest

import responses
import requests

import stackinabox.responses
from stackinabox.stack import StackInABox
from stackinabox.services.hello import HelloService


@responses.activate
def test_basic_responses():
    StackInABox.reset_services()
    StackInABox.register_service(HelloService())
    stackinabox.util.responses.responses_registration('localhost')

    res = requests.get('http://localhost/hello/')
    assert res.status_code == 200
    assert res.text == 'Hello'

There is now also the option of using a decorator:

import unittest

import requests

import stackinabox.util.responses.decorator as stack_decorator
from stackinabox.services.hello import HelloService


@stack_decorator.stack_activate('localhost', HelloService())
def test_basic_responses_with_decorator(self):
    res = requests.get('http://localhost/')
    self.assertEqual(res.status_code, 200)
    self.assertEqual(res.text, 'Hello')

Requests Mock

requests-mock works well with class-based tests, however, it does require that you use the Python requests API. If you use requests-mock directly than you also have to configure requests.session.Session objects and setup your code to use them. However, Stack-In-A-Box makes that unnecessary by providing thread-based session objects that are automatically registered and patching requests to return them automatically. Thus you can either use a Session object directly or just use the nice calls that requests provides and your tests will still just work.

import unittest

import requests

import stackinabox.util.requests_mock
from stackinabox.stack import StackInABox
from stackinabox.services.hello import HelloService

class TestRequestsMock(unittest.TestCase):

    def setUp(self):
        super(TestRequestsMock, self).setUp()
        StackInABox.register_service(HelloService())
        self.session = requests.Session()

    def tearDown(self):
        super(TestRequestsMock, self).tearDown()
        StackInABox.reset_services()
        self.session.close()

    def test_basic_requests_mock(self):
        # Register with existing session object
        stackinabox.util.requests_mock.requests_mock_session_registration(
            'localhost', self.session)

        res = self.session.get('http://localhost/hello/')
        self.assertEqual(res.status_code, 200)
        self.assertEqual(res.text, 'Hello')

    def test_context_requests_mock(self):
        with stackinabox.util.requests_mock.activate():
            # Register without the session object
            stackinabox.util.requests_mock.requests_mock_registration(
                'localhost')

            res = requests.get('http://localhost/hello/')
            self.assertEqual(res.status_code, 200)
            self.assertEqual(res.text, 'Hello')

There is now also the option of using a decorator:

import unittest

import requests

import stackinabox.util.requests_mock.decorator as stack_decorator
from stackinabox.services.hello import HelloService


class TestRequestsMock(unittest.TestCase):

    @stack_decorator.stack_activate('localhost', HelloService())
    def test_basic(self):
        res = requests.get('http://localhost/')
        self.assertEqual(res.status_code, 200)
        self.assertEqual(res.text, 'Hello')

We’ve Got Issues

Check out the Issues and Milestones tabs. They offer great starting points for making an effective contribution. If you find an issue or think of something that you’d like to see in the stack, the Issues page is the place to put it.

Feedback counts as a contribution, too, and it’s the easiest one you can make.

Reviews

Except for feedback, every contribution begins with a pull request. In order to keep knowledge of StackInABox distributed, we encourage code review here.

Testing

We are aiming for 100% unit test coverage. Presently we have about 74% coverage. Once 100% test coverage is achieved then it will be required - no questions asked. Until then, please help us achieve that or at a minimum maintain the status quo.

To be clear about definitions, a unit test is one that:

• Tests expected functionality

• Does not utilize unpredictable functionality (e.g., time.time)

To run tests:

tox

Style

To be sure your contributions are compliant:

tox -e pep8

Misc.

Here are the tenants in order of importance:

• Correctness - incorrect code is useless

• Simplicity - easy to use, easy to understand

• Consistentency - new interfaces should feel like existing interfaces

• Easy of use - users will only use it if it’s easy and not burdensome

• Performance - almost doesn’t matter. “Optimization is the root of all evil”.

  • Address performance when it becomes a problem. Don’t make it a problem before it is.

• Few dependencies - must be simple, explicit and not require a lot of things to be installed

  • Reduces the potential for issues with other projects

  • Keeps the ability to integrate into other projects high