DEV Community: mistermocha

In defense of Cat5e

mistermocha — Mon, 16 Oct 2017 18:01:41 +0000

A few years ago, we bought our house. This was my first house that I owned instead of rented. I was super excited to run patch cables through the walls, set up a networks switch and patch panel, and have keystone jacks strategically placed throughout the house. It was a silly engineering fantasy to have a garden of cables growing in a closet somewhere.

I dug in and did my research on what I should get and what I should buy for everything. I counted rooms and did a bulk order on Monoprice for RJ45 connectors. I did found an excellent crimper and stripper in a pack on Amazon. I invested in ENT tubing (a.k.a. "Smurf" tubing, because of how blue it is) and spent my first weekend in the house running it behind all the drywall. I then got to looking at cable. I chose Cat5e.

Now mind you, Cat5e was not an arbitrary choice. There were several factors which ultimately settled me on this choice. I still get flack from friends and colleagues for this choice, but I'm still happy with it and here's why:

Cost: I initially saw how much more Cat6/6a cost than Cat5e. Cat7 was barely tickling the market when I started on this journey so I left it off my list. Generally speaking, the best prices I found at the time showed Cat6 costing about 50% more than Cat5e when buying spools. Since this was the biggest purchase across everything, and I was trying to be a responsible homeowner, I decided to interrogate and justify the added expense of higher quality cable.
Speed: Cat5e is rated to cap out at 1GbE whereas Cat6 and "better" cables are rated for 10GbE. Even now, years after my installation, my ISP isn't capable of providing 1GbE to my house, so higher quality cables provide no benefit there. Source: https://www.digitaltrends.com/computing/differences-between-ethernet-cables/
Signal Quality: 1GbE, or officially 1000BASE-T, sets the standard for signal degradation at 100m. The longest run in my house is under 15m. If I were running to a property across the street, I might consider something higher quality. Source: https://en.wikipedia.org/wiki/Gigabit_Ethernet#1000BASE-T ... Similarly, the next biggest expense in my install was the switch, and 10GbE switches were similarly more expensive than 1GbE switches as well.
Ease of Installation: Cat6 cables have a plastic divider down the length of the cable. Cat6a got rid of this divider, but increased the wire gauge. Both are far less pliable than Cat5e and the divider makes crimping a major pain.

Considering all this, I chose to adopt Cat5e. I decided that for now I did not want to invest the extra coin into the higher standard. It ultimately wasn't worth it for me until they could run faster than 1GbE to my premises. If I were serving production traffic from my home and needed rapid synchronization of cache across racks, then sure, but I have a single server in my closet and a couple raspberry pi devices.

If for some reason I have the motivation to replace my cables, then I'm all set with my smurf tubes. 3/4" was sufficient to support redundant cables, so each drop has two runs. I hardwired my wife's desktop, a few entertainment devices (e.g., the Roku), and the "docking station" (series of dongles) for my workstation. The bulk of network traffic in my house now happens over hard wires instead of wireless, and all the cables are buried behind the drywall.

I decided to write this because of two reasons:

The recently discovered flaw in WPA2 (https://www.wired.com/story/krack-wi-fi-wpa2-vulnerability/) is yet another example that wired is inherently more secure. Broadcasting everything you're doing is far less safe than sending signals down a wire.
Every time I write down Cat5e, there's someone who jumps up and says "Why not Cat6/6a/7 or fiber?" So now I can copy-paste a link to this write-up and have a canned response.

A Very Brief Evolution of SRE

mistermocha — Wed, 31 May 2017 23:12:14 +0000

This is an opinion piece I'm writing for fun. Please don't take this seriously.

I'm an SRE. I've been a SysAdmin. I've been in Operations. I've been in tech support. I've been in this industry a long enough time to see the relationships between these titles and the tasks therein.

Here's my short list of the evolution of SRE, showing how technology evolves and titles mean things. For me, this has been a career evolution, as I've moved generally through these titles as I worked through my career, but titles like "DevOps" and "SRE" weren't as common until later in my career (earlier in history). Note that each title will likely include the tasks from any and all titles before/above:

Tech Support: The person you call when the webserver is down
Operations: knows when to restart the webserver (not likely to have access though)
SysAdmin: restarts the webserver
DevOps: writes a fancy script to restart all the webservers
SRE: turns the fancy script into a service that restarts the webservers for you, which requires a webserver that someone has to restart at some point.

Happy Wednesday people!

Python unit testing with Mock - Part Two

mistermocha — Wed, 10 May 2017 20:15:00 +0000

How do you write tests?

Python has many frameworks for writing tests, but ultimately they come down to collecting functions whose names begin with test from an organized namespace. This article, being the sequel to "Python unit testing with Mock - Part One", isn't here to help organize your namespace (for the record, that's best done with py.test which deserves its own glorious article).

This article will show you how to write tests, and understand when and how to use the mock module. It's one thing to just know "oh, that's how a mock works" but another entirely to know how to apply a mock to test your code properly. This article seeks to address that bit of knowledge.

How do I actually use mock now?

Having all the tools doesn't necessarily mean knowing how to use them! When I first read the documentation for mock, I found it baffling. I really didn't understand how to put it all together. Here's some practical-ish examples of how to read your code and decide how to craft a test.

Example #1

Let's touch upon an example similar to one we witnessed in the previous article. Here's a function that uses the requests library.

def get_example():
    r = requests.get('http://example.com/')
    return r.status_code == 200

In this function, we have an instantiated request r and view the status_code property on the object. The requests object is what talks to the outside world, but our code that implements requests is what we want to test out.

What we need to do is replace the return of requests.get() with a mock. We're going to use a variety of the features of mock to replace it properly.

@mock.patch('requests.get', autospec=True)
def test_get_example_passing(mocked_get):
   mocked_req_obj = mock.Mock()
   mocked_req_obj.status_code = 200
   mocked_get.return_value = mocked_req_obj
   assert(get_example())

   mocked_get.assert_called()
   mocked_get.assert_called_with('http://example.com/')

Let's walk through this to show what we're doing and why

mock.patch patches requests.get with a mock (meaning the get function in the requests library) using autospec=True to match the signature of requests.get.
This patched object is made available as the first argument, which we receive in mocked_get.
We know we need to create a return to feed into r in the code we're testing, so we create mocked_request_object. In the code, we only examine the status_code, so we declare that value - in this case, 200
We then assign mocked_request_object to the return_value of mocked_get, which is what will be returned when the patched function gets called
Since we know the function effectively returns boolean, we can call a simple assert on the function's return.
To ensure the mock was called properly, we call the built-in assertion methods. assert_called ensures the mocked requests.get was actually called, and assert_called_with checks the args. We can do similar introspection on the returned mock as well.

Now this seems like a lot of test code (8 lines) for a small function (3 lines). It's often the case that a python unit test could have more LOC than the code it's testing. We don't even have complete test coverage, because 200 isn't the only valid response! Test code should write faster than product code, since it doesn't involve the same level of thought or design.

This was only an example to show how to design a mock to replace an interface library. The principle here is to understand what part of your code talks to the public and do the minimum to replace it.

Example #2

It's called a "mock" because it can pretend to be something real. We know our code, so now we can examine our code to determine how to use a mock. We have a good overview of the parts and usage, but implementation is everything.

When looking at your code and deciding how to test, you want to run a test that ensure the desired outputs and side effects happen when executing your code. Ideally, you want to ensure at least one, if not multiple, tests happen for every line of code. So, tests should cover each function and mocks should prevent those functions from hitting the outside world.

Here's an example of a module that writes to a database:

class DBWriter(object):
    counter = 0

    def __init__(self):
        self.db = DBLibrary()

    def commit_to_db(self, sql):
        self.counter += 1
        self.db.commit(sql)

    def save(self, string):
        sql = "INSERT INTO mytable SET mystring = '{}'".format(string)
        self.commit_to_db(sql)

    def drop(self, string):
        sql = "DELETE FROM mytable WHERE mystring = '{}'".format(string)
        self.commit_to_db(sql)

Now this module uses a made-up API module called DBLibrary. Let's assume DBLibrary is an external library that is already trusted to work. We know that such a library has a couple features to note:

It is outside of this code
It may already have its own tests - even if it doesn't, refer to previous point
It can change state in a database

Those are all perfectly qualifying characteristics for something ripe for being mocked away. Now that said, we need to write tests for DBWriter, which is OUR library. Let's look at the behaviors of this module. The effective save and drop actions do the following:

Prepare the sql statement
Write the statement to the database
Increment the counter

All of these behaviors are elements to test, but we still want to protect the database from any writes. How do we do it?

Model #1 - Patch `commit_to_db`

The actual writing to the database happens in the commit_to_db function. We can replace this function with a mock and replicate the behavior. It does two things:

Increments the counter
Calls self.db.commit to commit to the database

Here's how you write that test:

@mock.patch('dbwriter.DBWriter.commit_to_db', autospec=True)
def test_save(mock_commit):
    writer = DBWriter()

    def fake_commit(self, sql):
        writer.counter += 1

    mock_commit.side_effect = fake_commit

    writer.save("Hello World")

    mock_commit.assert_called_with(writer,
        "INSERT INTO mytable SET mystring = 'Hello World'")
    assertEquals(writer.counter, 1)

Note the namespace assumes DBWriter is in a filename dbwriter.py or otherwise such organized module. You'll need to know your module's namespace for this patch to work.

The @mock.patch decorator replaces the commit_to_db function in place. We declare autospec=True which matches the signature to ensure commit_to_db is called correctly.

We also add a side effect, which is something that happens besides containment of a return value. commit_to_db doesn't just write to a database, but it also increments a counter. Adding this behavior in as a side effect ensures this action doesn't omitted when the mock is called. Since we're replacing the function with a mock, the actual code of that function never gets called.

Calling the mock in this way gives us the following benefits:

Introspection into commit_to_db: we can call mock's introspection tools to ensure that the function is receiving the right arguments
Insulation from write actions: We don't bring up an equivalent action to self.db.commit in the test, which means we've removed the action that can potentially write to the database.

However, this comes with some drawbacks:

Lost introspection into self.db.commit: We may be insulated, but we don't know if we're calling the function right.
No exercise of the actual commit_to_db: We're re-writing the non-state-changing code in our unit test! If that line were something more complex, or if there was a ton of code in here, we'd have to reimplement it all!

Now let's try another approach:

Model 2: Patch self.db.commit

@mock.patch('dbwriter.DBLibrary', autospec=True)
def test_save(mock_dblib):
    writer = DBWriter()
    writer.save("Hello World")
    mock_dblib.return_value.commit.assert_called_with(writer,
        "INSERT INTO mytable SET mystring = 'Hello World'")

Note that we're patching DBLibrary directly in the dbwriter namespace, which prevents patching that library elsewhere. This is direct surgery.

Doing this replaces the DBLibrary with a mock. Again, autospec=True will ensure that calls to commit and any other implemented methods will respect calls that match the given signatures of those methods.

Here's what we get for testing this way:

Insulation from the database: same as before, just in a different way
Introspection into how we use the DBWriter module: notice w're calling assert_called_with and determining how we call the function that actually writes to the database, with the same protections
Full exercise of every line of code in our test: only external code is replaced by the mock

Here's what we lose:

Introspection into the parent function: We don't see how the function is called by it's neighbors inside the module

Luckily, both tests are valid and can be done in parallel. If you're not sure which test to write, write both! You can never have too much test coverage.

Example #3

I'm often asked about how to mock something that gets instantiated multiple times in an object. A class coming up will instantiate a module twice (e.g., two separate database connections). Just naÃ¯vely patching the base module may give you one instance that gets used twice, or just spit out default mocks that don't help you at all. It took me some research and experimentation to figure out how to do this.

So, here's some example code:

from some.library import AnotherThing

class MyClass(object):
    def __init__(self, this, that):
        self.this = AnotherThing(this)
        self.that = AnotherThing(that)

    def do_this(self):
        self.this.do()

    def do_that(self):
        self.that.do()

    def do_more(self):
        got_it = self.this.get_it()
        that_too = self.that.do_it(got_it)
        return that_too

self.this and self.that are both instances of AnotherThing but initialized with this and that respectively. They're both used throughout the code. We want to patch out AnotherThing so we can decidedly test our code out.

We can take two approaches here, with some caveats. Ultimately, the options you choose have to do with how you implement the code.

Approach #1: Patch `this` and `that` directly

This approach works if you know for a fact that __init__ for MyClass and the initialization of AnotherThing didn't actively change state:

def test_my_class():
    my_obj = MyClass("fake this", "fake that")
    my_obj.this = Mock(spec_set='some.library.AnotherThing')
    my_obj.that = Mock(spec_set='some.library.AnotherThing')

    my_obj.do_this()
    my_obj.this.do.assert_called()
    my_obj.do_that()
    my_obj.that.do.assert_called()

In this approach, we instantiate and then patch the result in place. It's a straightforward approach that only really works when you know that your code will fit the pattern. It's highly unlikely that state changes happen in __init__ code, but entirely possible. It's also more likely that instantiating AnotherThing will be slow and expensive, even if it wasn't changing any external state. So this may be less confusing, it's not necessarily better.

Approach #2: Mock Generator

AnotherThing returns an instance of AnotherThing, so why not just change that action to spit out mocks?

@patch('yourcode.AnotherThing', autospec=True)
def test_my_class(mock_thing):
    def fake_init(*args):
        return Mock(*args, spec_set='some.library.AnotherThing')
    mock_thing.side_effect = fake_init

    my_obj = MyClass("fake this", "fake that")
    my_obj.this.called_with("fake this")
    my_obj.that.called_with("fake that")

mock_thing is the in-namespace patch to replace AnotherThing. We take advantage of using side_effect to return a spec_set mock. Now we've patched AnotherThing using mock.patch to spit out mocks that look like the objects it creates. All my patching happens before instantiation, so there's no modification of the code object being tested here.

Additionally, the mocks permit introspection, so we get to test usage as well!

To mock or not to mock?

There are times when it's necessary and appropriate to mock, and we've covered some examples of when it's absolutely necessary for the scope of a unit test:

Calling an API
Connecting to a database
Using the command line

Those are some obvious examples to consider. Let's look at some less obvious ones, and a reason not to mock as well

Don't mock the filesystem. A great explanation why can be found at Moshe Zadka's blog. The filesystem is huge. Really huge. Trying to mock it out would be a huge awful mock with a lot of edges to replace. If you need a filehandle, make a fake one using StringIO, or just write to a temporary file using tempfile. Both are standard library and easy to implement.
Acceptance tests are how we ensure our code works with the rest of enterprise imports and third-party libraries. Don't ignore that these libraries could change in unexpected ways. Write your unit tests, but write some acceptance tests for occasional runs
Integration tests by definition are there to test how your code integrates with the rest of the environment. You will want to occasionally test the real API call at some point.
Mock slow libraries to speed up your unit tests. Some code is expensive to instantiate, but doesn't really need to come up fully for a test. Abstract this away.
If you're writing tests, you're doing it right!

Python unit testing with Mock - Part One

mistermocha — Wed, 10 May 2017 20:14:02 +0000

What is this article?

Months ago, I was asked to give a talk to the Puget Sound Python Meetup group. This is the article-rendering of that talk. This talk makes some assumptions that you know the basics about how to actually write a test for python code and need to know how to embed mocks to keep your code safe.

When I was asked to give this talk, I was (and still am) responsible for a big script that talks to tons of external services:

kerberos
git
aurora
package repo
jira
email
shared libraries

This posed the question of how do I test my code without touching these services?

Note this article is going to be exclusive to the mock test library. Structuring overall tests is another topic and deserves its own article, which I have yet to write at this point. When I get there, I'll let you know!

What is testing?

Testing makes sure your code behaves as expected by running your code and observing the results. By actually running chunks code, it's the most assured way to know that it runs, how it runs, and that it does what is expected.

When writing tests, you can categorize into one of three approximate buckets.

Unit: Just this small part
Integration: When all the parts talk to each other and included parts
Acceptance: When the whole app talks to everything else

This article will focus on the best use of mocks, and that's for writing unit tests. Mocks could potentially have a place in integration tests, and the application wouldn't change.

Some code is easy to run to make sure it does what is expected. Here's a quick function and unit test that you might see:

### code ###
def double_up(number):
    return number * 2

### test ###
def test_double_up():
    assertEquals(double_up(2), 4)

The unit test simply runs the code and compares the received output to the expected output. Just like previously stated, testing means running your code

Now for some fun...

How would you test this

How would you test this block of code without actually deleting anything?

def wipe_directory(path):
    p = Popen(['rm', '-rf', path], stdout=PIPE, stderr=PIPE)
    if p.wait():
        raise Exception('We had a fail')

How would you test this block of code without actually deleting anything?

def delete_everything():
    r = requests.post('http://example.com/',
        data={'delete': 'everything', 'autocommit': 'true'})
    if r.status_code == 200:
        print('All things have been deleted')
        return True
    else:
        print('Got an error: {}'.format(r.headers))
        return False

How would you test this block of code without committing any change to the database?

class DBWriter(object):
    counter = 0

    def __init__(self):
        self.db = DBLibrary()

    def commit_to_db(self, sql):
        self.counter += 1
        self.db.commit(sql)

    def save(self, string):
        sql = "INSERT INTO mytable SET mystring = '{}'".format(string)
        self.commit_to_db(sql)

    def drop(self, string):
        sql = "DELETE FROM mytable WHERE mystring = '{}'".format(string)
        self.commit_to_db(sql)

Trying to actually execute these blocks of code will modify external state. These examples either execute a shell command, talk to an API, or connect to a database, all of which are actions that happen outside of the execution space of the written code.

What is mocking?

unittest.mock is a library for testing in Python. It allows you to replace parts of your system under test with mock objects and make assertions about how they have been used.

Source: https://docs.python.org/3/library/unittest.mock.html

As stated earlier, mocks are primarily used for unit testing. There may be some place in integration testing, highly unlikely in acceptance testing.

Why should you mock in your code?

Unit test safely: stop the state-changing parts so you can actually run tests
Write better code: a lovely side-effect of writing thorough tests
Isolation: create walls between your code and "not-your-code" for safer tests

About the mock library

Mock objects intend to replace another part of code so that it pretends to be that code. In this example, let's assume that visible_method is a function inside of MyClass that runs sub_method. Now let's assume that sub_method does something we don't want to run in the scope of this test. We simply replace sub_method with a Mock instance.

from unittest.mock import Mock
from mycode import MyClass

def test_myclass():
   my_object = MyClass()
   my_object.sub_method = Mock()
   my_object.visible_method()
   my_object.sub_method.assert_called_with("arg", this="that")

This isolates one function from talking to another function within the same class. A mock becomes a synthetic code object that simply runs and returns another Mock object successfully every time (with some exceptions). Unless you're expecting something specific, a raw mock object can drop in almost anywhere.

However, most functions expect something specific, and this is the main purpose of a mock. You can shape a mock up to look like anything. Prop it up to behave like a specific function, module, class, object, etc. and you'll avoid having to do dicey things like call a database API. We'll get more on this in some of the next examples.

Using mock.patch

Sometimes, the dropping-in of an object is not as easy as directly replacing a function in a namespace. Sometimes the object to replace is much deeper down. By adding the @mock.patch decorator to a function, you can replace an object directly in the namespace with a mock.

Here's a function that has subprocess.Popen available in its namespace. We can't directly replace it as we did in the prior example.

def count_the_shells():
    p = Popen(['ps', '-a'], stdout=PIPE, stderr=PIPE)
    if p.wait():
        raise Exception('We had a fail')
    count = 0
    for proc in p.stdout.readlines():
        if "-bash" in proc:
            count += 1
    return count

The subprocess.Popen is inside the function, but it's available in the namespace of the function. By @mock.patching, we replace subprocess.Popen with a mock. The PIPEs no longer are used because of the replacement, so we don't need to patch them.

By examining the action in this function, we see its surfaces that talk to the subprocess object that gets returned:

Popen runs a command line execution and returns a subprocess object. In this case, p
p.wait() blocks until it gets back the shell's exit code and returns it as an integer.
p.stdout is a filelike object that captures STDOUT

Our mock then needs to have these surfaces as well. We don't need to completely replace the behavior of a Popen call, we just need to make the return value look like the return value of a Popen call and the methods that we use.

@mock.patch('subprocess.Popen')
def test_count_the_shells(mocked_popen):
    mocked_popen.return_value.stdout = open('testps.out')
    mocked_popen.return_value.wait.return_value = False
    assert count_the_shells() == 4

Let's take a look at what's going on in this test:

@mock.patch decorator replaces subprocess.Popen with a mock object. That gets passed in as the first argument in the test function. The test function receives it as mocked_popen
The Popen call returns a subprocess object. We're now amending the return_value of that object by applying behavior to stdout and wait, which get used in the function
Now when count_the_shells is executed, it calls the mock instead of Popen and gets back expected values.

We've effectively replaced subprocess.Popen with a mock that behaves like that object as far as the function is concerned. Now you know how to replace a method with a mock that actually mocks something!

But wait, there's more!

Spec and Autospec

What if your mock could just be pointed at a module and automatically look like that module? What if it could be prompted to just respond to functions already defined in a module with mocks? Seems like just the python-majick we have come to expect and love, right? Well, read on!!

A mock will have its own built-ins, but any other call received will simply return another mock. This plastic behavior looks like this:

>>> mock = Mock()
>>> mock.this_is_never_assigned('hello')
<Mock name='mock.this_is_never_assigned()' id='4422797328'>

This prevents accidental calls from blowing up your code, but, leaves room for a lot of error. You can obtain safer instantiation by autospeccing - make the mock behave like more like the thing you're mocking. Passing the spec argument tells the mock to closely behave like another. Mocks instantiated with spec=RealObject will pass isinstance(the_mock, RealObject).

>>> from collections import OrderedDict
>>> mymock = Mock(spec=OrderedDict)
>>> isinstance(mymock, OrderedDict)
True
>>> type(mymock)
<class 'mock.Mock'>

Using spec also affords protection, preventing calls to undeclared attributes. You can declare any additional attributes you wish.

>>> mymock = mock(spec=OrderedDict)
>>> a = mymock.this_does_not_exist()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/twitter/lib/python2.7/site-packages/mock.py", line 658, in __getattr__
    raise AttributeError("Mock object has no attribute %r" % name)
AttributeError: Mock object has no attribute 'this_does_not_exist'

>>> mymock.this_does_not_exist = "this exists now"
>>> print(mymock.this_does_not_exist)
this exists now

Instantiating with spec_set is an even stricter spec. This prevents amending missing attributes. Attempts to define undeclared attributes will fail on AttributeError

>>> mymock = Mock(spec_set=OrderedDict)
>>> mymock.this_does_not_exist = "o no you didn't"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/twitter/lib/python2.7/site-packages/mock.py", line 761, in __setattr__
    raise AttributeError("Mock object has no attribute '%s'" % name)
AttributeError: Mock object has no attribute 'this_does_not_exist'

Using the create_autospec function is even stricter. This will generate mock functions defined to spec that will enforce function signatures, meaning if the original function expects two positional and one keyword argument, then the mocked function will also expect two positional and one keyword.


>>> def myfunc(foo, bar):
...     pass
...
>>> mymock = create_autospec(myfunc)
>>> mymock("one", "two")
<MagicMock name='mock()' id='4493382480'>
>>> mymock("just one")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 2, in myfunc
TypeError: <lambda>() takes exactly 2 arguments (1 given)
>>>

Appropriate use of spec can help you write cleaner code and catch typos. Since a spec_set locks out unimplemented methods, your test code will fail if it has a typo too.

>>> mock = Mock(name='Thing', return_value=None)
>>> mock(1, 2, 3)
>>> mock.assret_called_once_with(4, 5, 6)
# typo of "assert" passes because mock objects are forgiving

>>> from urllib import request
>>> mock = Mock(spec=request.Request)
>>> mock.assret_called_with
Traceback (most recent call last):
...
AttributeError: Mock object has no attribute 'assret_called_with'
# since "assret_called_with" is a typo, it's not declared. Proper exception caught!

Also, in python 3, you can name your mocks, which shows in the repr of the mock. This is useful for debugging! You can see exactly where in your code your mock blew up because you know which of your mocks was misused!

Introspection

Mocks come with a long list of built-in functions that provide a level of introspection into the life of the mock. There are storage attributes that automatically store every function call in the mock. These are built-in attributes and functions for inspecting how the mock was used:

called - boolean, true if ever called
call_count - integer, number of times called
call_args - mock.call() object with args from last call
call_args_list - list of mock.call() with all args ever used
method_calls - track calls to methods and attributes, and their descendents
mock_calls - list of all calls to the mock object

If you have a mock object passing deep through your module, and you want to make sure it's actually referenced and not missed over, the called method is your friend. Similarly, call_count can confirm how many times, and call_args confirms what args were used the last time.

Now since this is for unit tests, assertions are the common way to write tests. To make this better, mock has built-in assertion functions that reference the aforementioned attributes:

assert_called - if ever called
assert_called_once - if called exactly once
assert_called_with - specific args used in the last call
assert_called_once_with - specific args are used exactly once
assert_any_call - specific args used in any call ever
assert_has_calls - like "any_call" but with multiple calls
assert_not_called - has never been called

So you don't have to wrap up booleans in if statements, you can just use the built-ins.

Summing Up - Part One

In this article, we covered the usage and features of the mock module in python. We discussed how to apply a mock to an existing test and how to adjust its behavior.

In Python unit testing with Mock - Part Two, we'll cover how to review your code to decide what parts of your code require mocks, how to write them with real code samples, as well as some cases where you might want to mock, but shouldn't.

Yes! You can plan your projects!

mistermocha — Fri, 28 Apr 2017 22:28:41 +0000

This is my first article here. I'm welcoming of feedback so I can make this better.

Project planning. It's what makes engineers productive. You should definitely do it.

What's that? You already do? You already know how to plan a project? Okay, what do you do first? Start coding or write a project plan?

I was the same way too, once. I admit to just jumping in and coding my way into a corner. I thought I was saving time, but instead I burned up a ton of time. I'm writing this article to distill down what I went to two different universities to learn about, in conjunction with over a decade of industry experience, so congratulations! You've read my article and saved tens of thousands on tuition and caught up to my current career!

Terminology - not really just making up words

For sake of this article, I'm going to use some simple terms that may equate to your place of business (or not-business, you might work on your own project, a non-profit, volunteer group, etc.)

Goals - the things you kinda sorta know you definitely want

In a workplace environment, the people/business/organization/etc will need to accomplish things. We'll call them goals. Goals can be more nebulous, like get more users or speed up deploy time. Companies may call these something different, like "objectives."

A measurable goal is just that, measurable. One can take a metric and review before and after some time and effort to see a result. Such goals may look something like these:

Reduce number of alerts
Speed up deploy time
Reduce CapEx budget

An immeasurable goal is not something where a simple metric can be applied, but it is clear to a human observer that there has ben a change. Some aspects may be measured (more on that later), but the overall goal doesn't have a metric. Such goals make look something like these:

Improve operational overhead
Become more proficient in Java
Improve team morale

Projects - The pieces of that goal that must be done

When a goal is in mind, a project can be defined to work towards that goal. Goals can be observed, but don't have to be measurable. Projects should absolutely be measurable. Additionally, a project should be generally time-scoped. Consider what you can get done in the next quarter/half/etc. This can be helpful during review cycles.

Let's define a few projects based on a few goals from before:

Reduce number of alerts:
- Configure 50% of stateless services for automatic instance remediation
- Upgrade MySQL hosts from 1G to 10G NICs
Speed up deploy time:
- Migrate main backend service to SSDs
- Examine and implement service warmup settings in FooBarBaz service
Become more proficient in Java
- Complete 30 HackerRank challenges
- Make at least one "major" production code change in a Java repository

Some projects are incremental and will have a ratio of completion. Assume that you have six stateless services on your team, but you feel you can only handle three of them this quarter. Then your project can theoretically progress 1/3 at a time.

When planning projects out that have a metric attached, it should be known how to measure that metric. Adding a metric may be a goal in and of itself. For speed up deploy time goal, you may need to start measuring your actual deploy time before you can actually start. Draw that up as a project and get to it first!

At Twitter, we use OKRs to plan our work. Objectives are the word we use for the unstructured goals. Key Results are what we use to define projects as a measurable chunk of work to be done.

Tasks - the things that actually get done

Projects are specific, but not necessarily a discrete unit of work. We'll call them tasks. Tasks are specific units of work. Let's define a few tasks for some of our projects:

Configure 50% of stateless services for automatic instance remediation
- Define standard alert set for our stateless services
- Bind service X to standard alert set
- Hook up service X to remediation platform
- Bind service Y to standard alert set
- Hook up service Y to remediation platform
- Bind service Z to standard alert set
- Hook up service Z to remediation platform
Upgrade MySQL hosts from 1G to 10G NICs
- Acquire 2 10G hosts for testing
- Test production services against 10G hosts
- Fix cmalloc startup bug
- Acquire 8 10G hosts for production rollout
- Production cutover
- Set up deploy config changes
- Set up service config changes
- Run production deploy

Sometimes, these specific units of work may involve even smaller units of work. Try to avoid task inception though (sub-tasks within sub-tasks). Hours can be wasted managing projects too deeply, but it's sometimes necessary. Our Production cutover here has several steps, but they're all in the same goal. It's your call if you want to run those tasks hierarchically.

You'll perhaps find that some of the tasks from your projects really belong to other colleagues or teams. For example, host acquisition may take several days or weeks depending on approvals and provisioning - specifically, work done by other people. Now you've discovered blocking tasks, and those are good to identify and kick off right away. You can't test until you get those test hosts, so order them right away and switch over to another task while you wait.

Project management - be your own boss?

Now, how do you manage these things going forward? Project planning leads into project management. Now if you're a reasonably-sized tech company, you might use Jira for managing your work items. Goals are something that you have stuck to the wall on a poster, where as projects and tasks equate to Jira epics and stories/tasks.

Atlassian, the company that makes Jira, published an article that gets into the details of how to manage projects using epics and stories/tasks.

Getting things done - look at what you wrote down!

When projects are planned this way, as units of work that stack up towards a given goal, then the work you're doing is clearly trending towards that goal. Now I know you probably don't want to write out another task in Jira, or Asana, or whatever else you may have at hand, but it's definitely worth it to have and use these tools.

Sprint planning - just look at your list and decide what's next

Regardless of the tool you use, USE IT! Look at your lists of tasks. Jira lets you create a thing called a Kanban board, that's straight out of any Agile textbook. You have columns for tasks that are not yet worked on, currently working, and done.

backlog	in progress	complete
Order Hardware	Analyze existing setup	Kickoff meeting
Upgrade Jenkins
Better monitoring

You can IMMEDIATELY see the state of what's going on with your projects, which is a fine feeling. When the manager says "How's the Jenkins migration going?" She can look at your Kanban board and see your progress. Amazing! It's also a great feeling to see your backlog gradually grind down less and less.

Communication is your friend

OK, so you've done all the tasks for your project, and it's definitely working towards your goal. Now what? How does anyone know what you did? You tell them!

Most of us in the tech industry have weekly one-on-one meetings with our managers. This is where we tell our manager what we have on our plate and where we're blocked. Got a task that bob-from-accounting has been camping on since you got it to him? Tell your manager that you're waiting on it, and she should be the one to go try to move it along. Not enough budget for those SSD's? Discuss with your manager what the budget is like.

You should also let your manager know what you got done this week. This is how you build your reputation as a worthwhile engineer. You can say "hey, that goal that the CEO/VP/etc. set? Well, I got us two steps closer to that because of X!" She'll see how thoughtful you were with your planning and trust that you'll continue to work on the rest of your tasks.

The continued reminder of your successes and your intent on blockers will reinforce that perception of your ability to get things done. Then people won't mind as much that you surf reddit while your project is compiling.

Share your project work with your colleagues, but avoid bragging too much. Nobody likes a know-it-all, but nobody likes it when someone seems incompetent either. Moderation is key. A routine (bi)weekly email summarizing accomplishments is always a good thing. If nobody else on your team is doing it, start it and include team members' accomplishments. If someone else is doing one, then make sure your completed tasks get mentioned.

Brand is all about perception. It's about how others feel about you. You may not have direct control, but you do have an influence.

Prototyping - buyer beware!

Have you ever seen that one tool or service that nobody wants to touch because it never should've been shipped and nobody knows who owns it now? This is often the byproduct of somebody's hackathon project or a prototyped tool that was never really well planned. Prototyping is just writing a just-barely-minimum-viable-product to show that the idea has merit.

Drawing up a prototype should be done in the context of something like a hackathon. That's the space to throw something at the wall and see if it sticks. But, consider the hierarchy. The thing being built should work towards a given goal. That goal may be learn more about machine learning and the project of the hackathon may be build a basic ML model to predict something. You can plan your ad-hoc projects too!

Be careful when diving into writing code before planning a project. It's much easier to push things to production than it is to remove from production. Use a prototype to make decisions about what and how to build something, and spend as little time on it as possible until a proper project can be drafted.

Summary

Project planning for fun and profit! You can do it too! Plan and execute on your projects and you'll be climbing the ranks in no time! Follow these steps to success:

Define your goals
Set up projects that work towards those goals
Break up your projects into tasks and assign those tasks to people
When tasks are on other people or teams, raise awareness ASAP
Watch your task lists every day so you know what to work on next.
Tell your manager about what you've done
Prototype with caution

Hi, I'm mistermocha

mistermocha — Tue, 11 Apr 2017 06:26:15 +0000

I have been casually coding since 1999 when I started messing around with HTML and CSS. I've been professional at it to some degree since 2008 where I wrote Perl for an online advertising company.

You can find me on GitHub as mistermocha

I work for Twitter as an SRE.

I mostly program in python and some bash. Occasionally I touch scala and JavaScript too.

Nice to meet you.