Add first tests

[charlesreid1]

This builds on the add tasks pull request #31 and starts to implement tests of the single task that has been implemented so far.

As we continue to build out tasks in the add-tasks branch we will sync those changes into this branch and write more tests.

[charlesreid1]

Nice, our first test of importing and running works! We can set the payload handler and start the flask webhook server from a script. We have a debug mode implemented so time to write up a short script to send a fake webhook.

Debug mode should also be checked when doing github IP whitelisting check.

[charlesreid1]

Config file... missing? but still running?

[charlesreid1]

Nice, these tests are working well. We're currently testing imports of the webapp and the payload handlers.

To do: test imports of task objects, test ability to set custom config params

Nice to have: test ability to add new payload handler and add it to the factory and verify that it is working

[charlesreid1]

Currently we are planning on using docker for tests that require running the webhook server (in one window/shell) and sending fake webhooks to it (in another window/shell). Is there a way to do this with nose?

flask docs on testing: http://flask.pocoo.org/docs/1.0/testing/ (uses pytest)

• http://flask.pocoo.org/docs/1.0/testing/#other-testing-tricks
• http://flask.pocoo.org/docs/1.0/testing/#accessing-and-modifying-sessions

nose for flask testing: https://github.com/damyanbogoev/flask-bookshelf/tree/master/tests

relevant: using werkzeug and creating a flask client object https://behave.readthedocs.io/en/latest/usecase_flask.html

[charlesreid1]

Config file... missing? but still running?

This is b/c we were loading the config when the webhook route was loaded, not when the webapp was created.

[charlesreid1]

Somehow confused webhook config and flask config. We have implemented a webhook config file, that's loaded each time a webhook is received. We have referred to this as a flask config file, though. Why? Because we're using app.config. So we actualliy need to use a flask config file. That is, we need to set app.config using a config file.

[charlesreid1]

http://exploreflask.com/en/latest/configuration.html

Sometimes you’ll need to define configuration variables that contain sensitive information. We’ll want to separate these variables from those in config.py and keep them out of the repository. You may be hiding secrets like database passwords and API keys, or defining variables specific to a given machine. To make this easy, Flask gives us a feature called instance folders. The instance folder is a sub-directory of the repository root and contains a configuration file specifically for this instance of the application. We don’t want to commit it into version control.

[charlesreid1]

config file handlng worked out: when the user sends the webhook, we load the config file from an env var, UNCLE_ARCHIE_CONFIG, and look in the cwd if it is a relative path. Need to check if env var is set on instantiation of app instead.

[charlesreid1]

Currently, we have a flask test that runs a fake client and requests /. But server is returning {'msg':'pong'} 😑

[charlesreid1]

Here's the header from the fake client request, which should not trigger a 'pong' event:

root: INFO: User-Agent: werkzeug/0.14.1
Host: localhost
Content-Length: 0

[charlesreid1]

Relevant portion from flask app:

    # Play ping/pong with github
    event = request.headers.get('X-GitHub-Event', 'ping')
    logging.info(request.headers)
    if event == 'ping':
        return json.dumps({'msg': 'pong'})

[charlesreid1]

ohhh, b/c request.headers.get('X-Github-Event','ping') sets the value of event to 'ping' in case the header is not present.

Change flask app to:

    # Play ping/pong with github
    event = request.headers.get('X-GitHub-Event')
    logging.info(request.headers)
    if event == 'ping':
        return json.dumps({'msg': 'pong'})

[charlesreid1]

Forgot to add the dang render_template() handler.

Once that's done and test_run.py is passing we'll be ready to merge this into #31, and move on with task tests.

[charlesreid1]

This bad boy is ready for a merge.

[charlesreid1]

Back to #31