Welcome!

So this is the beginning of my test framework blog.

I've been meaning to do this for quite a while.  After working several jobs, and creating a very similar API test framework in each company I've decided to share a cookie cutter example of how to create a powerful, yet very lightweight test framework.

I"m going to write this tutorial style, with each post adding onto the next.  Therefore I suggest you start from the last post and work your way back.  In the git repo the Main branch will hold the latest iteration of the framework, and I will have a branch for each step.  Hopefully each iteration of the framework will be runnable.  I will let you know if it doesn't

Since I last created this framework in Python 3.5, it's what I will be using.  There are a few modules to install, as noted in the first blog post labeled "So Let's Begin".  My favorite python IDE right now is pycharm (pretty much the same as intellij).

Here is the github repo:  https://github.com/lightmanca/TheTestFrameworkBlog.
Both this blog and the github repo are protected under the Apache 2.0 License http://www.apache.org/licenses/LICENSE-2.0

From the "I'm overthinking this department"

Our current application framework uses bootstrap to get a lot of values for each environment (dev, test, prod).  All these values are read at the start of the application.

I have written a "Data Retrieval" app to get data from all the environments, so the data from whatever source can be manually verified with what's in our databases.  One of the features I wanted was to be able to switch environments while staying in the app, since it requires editing a config file, and then reloading the config.

A few hours of trying different incantations of commands trying to convince our app framework to reload itself.  Then suddenly it dawned on me.  Why not have the entire app restart, after all that's what I wanted to.  5 minutes after I got in the office and my problem was solved.  In this case an "Application.Restart()" command did everything I wanted.

An "extra credit" assignment would be to have it save it's state for the new instance of the app to use.  In this case, just the email email address to use for the query, though I'm not sure how useful it would be for anyone who isn't testing the data retrieval app itself [very unlikely you would be searching for the email address across environments].

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.