Adding more tests

Now we'll flesh out some of our test cases.  Our test suite is limited, because I'm hitting the limit of Twitter's requests/15 minute period after about 3 test runs.  I wanted to show the types of tests to make, and how the functions might interact with each other.

Data containers for REST calls and responses.

I would say most people using python probably wouldn't do this, but coming from a c# and java background, it's ingrained in my head to make container classes for data.  I think it helps keep track of the data.  Admittedly, I've done some tricky things to do to make generic methods to translate the fields into json (or some other payload), and back.  But once they are written you don't have to deal with it anymore.

Adding a container class for auth credentials.

First we are going add a container class for the service credentials we need to pass around.  I would also suppose that if we were going to encrypt these values, that having this container class be the place where the data is encrypted/decrypted makes sense (but we're not doing that right now).

Time to add some data classes, and add more test cases.

I've decided to break up the next bits of work into several blog posts.  The posts are described as follows:

• Adding a container class for auth credentials
• Adding data classes for twitter update status payload, and responses.
• Adding more test cases.  

I have one branch for all these changes: 

https://github.com/lightmanca/TheTestFrameworkBlog/tree/twitter_add_data_classes

So without further ado, here we go...

Adding test teardown.

I want to add a teardown method to my tests.  We've just been posting tweets, and not cleaning them up!  Frankly my reason for doing this is because the return json from getting my account timeline is huge.

Let's add some logging

It's time we added more tests.  To do that we can add a few things.  First up on our list of things to do is setting up logging.  Logging is very easy to do in Python.  Once you configure your log file, any instance of logger you make with the same "logger id" will output to the same file.  First we need a log file directory.  I'm making mine right in my project.  When running tests in a CI system I would probably put them somewhere else.  Also make sure the contents of your log directory are excluded from your source control.

For more information about python logging, go here:  https://docs.python.org/3/howto/logging.html

Let's start our framework!

Ok!  It's time to do some heavy lifting.

What we want to do make a web service client framework for our twitter requests.  This will consist of 3 classes:

A visit to config files.

Well we have some rudimentary tests, with no test framework.  However before we do any more work we need a place to store all those application keys.

The problem is that I almost committed the application keys to my github account, and once uploaded they're there forever!  Of course I would generate new keys, but I could do it again.  So the best thing to do right away is to find a home for these keys that are located outside the git repo, or put in the gitignore file.

When one of my former coworkers, a dev saw how I was storing all these values he was very quick to mention that if this was a production web service all those values would be stored in environment variables.  Here's the thing... a web service is running 1 instance of a particular service.  The api tests were testing against to 10 microservices, and 4 environments (dev, qa, beta, prod).  That makes 40 sets of configuration settings we need to keep track of.  In our example we would at least store 4 keys, and the twitter api url.  That would start getting messy.  So I devised in my config system a way to encrypt access keys, with a master key being stored somewhere else.  Much easier to keep track of one key than 160!

We'll revisit the config system with encryption and all that later.  For now all I want is a config file, and a way to read it.  A way for specifying the config file name on the command line would be nice.

So Let's begin!

At first I thought I would demonstrate against the Google Search API, but they don't really have one.  A little poking around, and I found the Twitter Api.  So that's what we're going with.  This is good because we should be able to demonstrate all CRUD activities with Twitter, and also how to deal with authentication, and how to store api keys (that will be well into the future).

The first thing we're going to do is create a twitter application, generate your twitter keys, and then create some quick and dirty tests to verify your twitter access.

Twitter's authentication is a little complex.  However I found a wrapper for httplib that will handle the oauth authentication, while still valid for our example.  So we move forward!