Michiel van Vlaardingen

There is excellent information available on testing Flask e.g. http://flask.pocoo.org/docs/0.12/testing/

One thing I ran into was the need to set up a user session for most of my test cases.
The documentation suggests something like:

with app.test_client() as c:
    with c.session_transaction() as sess:
        sess['a_key'] = 'a value'

but repeating that in every test case (especially with a bit more code to set up the session) is not really DRY.

Now the same documentation suggests a very elegant trick using context managers for setting up users on the global object:

from contextlib import contextmanager
from flask import appcontext_pushed, g

@contextmanager
def user_set(app, user):
    def handler(sender, **kwargs):
        g.user = user
    with appcontext_pushed.connected_to(handler, app):
        yield

Inspired by this, I figured that they can be combined into:

@contextmanager
def user_set(app, user):
   with app.test_client() as c:
       with c.session_transaction() as sess:
           start_user_session(sess, user)
       yield c

and then use it in a test like:

user = ...
with user_set(app, user) as client:
    client.get('/logged_in_resource')

Everyone who has ever coded anything significant  (and probably everyone who has ever done anything that requires creativity) will recognise the problem of getting stuck. Most of the time it is caused by lack of information or confidence to move forward. Over time I’ve identified a number of reasons I get stuck and also strategies to deal with this.

Perceived Dependencies

In larger systems, components often have to interact. If none of these components are properly defined or all need changes, it can be hard to get started.
Strategy: Fake a little, build a little.
It’s tempting to start things from the beginning and just write the code sequentially, however if things are not entirely clear it can work very well to start at a very very high level.
I usually just outline everything in 3 to four steps, each being a commented line. For example if I need to classify emails into categories, I might write something like:

// get e-mails
// get defined categories
// classify e-mails

Then write each step as code. This is the time you will need to start thinking about how data is passed around. Whether you will need objects or just lists of strings, etc.

// get e-mails
emails = get_emails()
// get defined categories
categories = get_categories()
// classify e-mails
classifier = new Classifier(categories)
for email in emails:
    scores = classifier.get_score(email)
    category = get_top_category(scores)
    print email.title, category

To test these assumptions you will need to actually implement the functions/components you’ve used. However, key to this strategy is to now fake these functions/components as much as possible.
e.g. I may implement get_top_category as:

def get_top_category(scores):
    return scores.keys()[0]

The reason to do this is not because I don’t know yet how to implement this, but because I don’t want to get stuck in details. (e.g. what happens if there is a tie, what if all are zero, etc etc) Things become so much easier when you have an end-to-end solution that just compiles.

Can’t wrap your head around it

You all know this feeling, but the cause is less clear. Ill defined tasks,  generic approaches,  feeling tired,  they all can lead to this.
Strategy: Second Pair of Eyes
Not everything needs to be solved on your own. If you are not clear on the ‘what’, just talk to a coworker, manager or customer. If you are not clear on the ‘how’ just start explaining to a coworker why you can’t move forward on this.
A very important part of this strategy is the need to explain and define your problem. Even the act of just explaining it may resolve the issue. In that case it’s called Rubber duck debugging: the act of explaining your problem to a rubber duck.

Choice

This is probably the biggest show stopper:  as soon as you are aware that there are multiple options with various tradeoffs, it’s hard to proceed.   I’ve seen bad programmers finish things quicker, just because they were happy with any solution that worked, in their universe there were no trade-offs to be weighed.
Strategy: Writing
If choice and tradeoffs are involved, you need to start writing. Just create a document with bullet lists of:

• Everything that is already given (e.g. API urls, relevant documentation)
• Requirements
• Important conditions (e.g. needs to work when device is offline)
• Potential issues (e.g. there may be too many items to fetch in a single API request)

Then for each of them come up with at least two approaches. Then for each of them also add potential advantages and downsides. And then again for each downside, figure out how to solve it.
For me this usually becomes a nested list of four or five levels.

One of the big advantages is that you can leave this for the next day to refine, without having to start all over again in your mind. Furthermore, you can easily refine this into documentation after the decisions are made.

Boring…

The idea of heaving to spend days to do some boring, semi-repeatable task that could have been avoided when better choices have been made in the past  can certainly demotivate you.
Strategy 1: Embrace it
Sometimes you’ve got plenty of energy, but can’t really move forward on an issue (e.g. due to one of the reasons mentioned above) this is the perfect time to do this boring task you’ve been putting off. It is 100% clear and every minute you spend on it will actually move you forward.
Strategy 2: Make it interesting
Boring things are also often the things that are easy to automate. This might be the right time to learn more about:

• advanced find/replace features in your IDE
• find/grep/sed on the commandline
• UI automation

Strategy 3: Delegate
What is boring to you, may be a nice task for someone else to learn a new skill. e.g. writing UI tests might be boring, but it can be a valuable and marketable skill for your intern.

Bugs

Lots of people get stuck on finding and fixing bugs.  But remember, in debugging there is always a next step to take.
Strategy: Identify and check your assumptions
At the root of every bug is a bad assumption. This can be an assumption on what your code will do, the contents of a variable or the correctness of an external dependency. Debugging is just identifying your assumptions,
I’ll write a follow up post on debugging strategies soon.

As a developer, I don’t particularly enjoy customer support. Questions are either about things that are obvious (or should have been) or about things that I don’t have a clue about either and need a lot of investigation. Some customers are just plain rude with “it’s not working” in the subject and nothing else.

At first sight it seems to be a huge waste of your expensive developer time to spend time on this. However, I strongly believe you should. Not only do developers bring value to the customer by providing more knowledge and understanding about the product. Providing accurate support is a guaranteed way to turn dissatisfied users into your most loyal customers. It also helps improving the product thus reducing support requests and increasing customer satisfaction.

Read all 5 reasons why in the full article

For Observu implementation we are using Pivotal Tracker to keep track of features and progress. I’ve posted a full review on our Observu Blog. To summarize:  the idea of having a single ordered list of features instead of just a bunch with priorities is amazing. It gives you so much more information and forces you to make decisions on what really needs to happen and what needs to happen first.

You’ve got so many ideas in your head that you just don’t know where to get started. As a result, you start procrastinating on stuff you do feel passionate about. At the same time, you’ve got enough energy and are motivated to get stuff done.  It’s a bit contradictory state of mind, that happens to me once in a while.

The problem is anxiety to commit to one project and  even more so: leave all those other things alone.  I believe the key to overcome this problem is to start on anything.  In the end it does matter much more that you’ve made progress and added value than it matters which choice you make.

Of course, that’s easier said than done. ‘Pick anything’  is still a choice and choices are hard. Therefore I use a very simple solution:  pick the easiest task that still adds value.   In the end you probably will have to do all those tasks anyway, so why not start with the easiest one?    Especially  in programming,  getting anything done, will give you more context to solve the next task.  Tasks that may have seemed daunting at first, become easier and better defined when the system around it takes shape.