Tuesday, January 8, 2013

ExpectedMockCreationError: Verify: Expected mocks never created:

I've been writing some unit tests for my code using pymox. This is (a simplified version) of the code I was testing, found in a python module called hashtag.py:

def Authorize():
  """Authorizes the user.

    An authorized instance of httplib2.Http.

  oauth_client = oauth.OAuth()
  credentials = oauth_client.Flow(SCOPES)
  auth_http = oauth_client.Authorize(credentials)
  return auth_http

And here's the (simplified) code I wrote to test:

import hashtag

class HashtagTest():

  def testAuthorize(self):
    """Test the authorize method."""

    expected_auth_http = self.mox.CreateMock(httplib2.Http)

    self.mox.StubOutClassWithMocks(oauth, 'OAuth')
    mock_oauth = oauth.OAuth()
    mock_credentials = self.mox.CreateMock(client.OAuth2Credentials)

    actual_auth_http = hashtag.Authorize()
    self.assertEquals(expected_auth_http, actual_auth_http)

While writing the tests, I ran into the following error:

Traceback (most recent call last):
  File ".../hashtag/hashtag_test.py", line 34, in tearDown
  File ".../mox/mox.py", line 333, in VerifyAll
  File ".../mox/mox.py", line 958, in _Verify
    raise ExpectedMockCreationError(self._instance_queue)
ExpectedMockCreationError: Verify: Expected mocks never created:
  0.  <MockAnything instance of OAuth>

This isn't very clear, but I do see that the error is being raised during the verifyAll step. A Google search for the error led me to the code, with the following docstring explaining the error:

Raised if mocks should have been created by StubOutClassWithMocks.

Looking at the Mox Documentation, the general workflow is as follows:
  1. Create mock (in record mode)
  2. Set up expectations
  3. Put mock into replay mode
  4. Run test
  5. Verify expected interactions with the mock occurred
I created a mock and set up the expectations that my code will create a mock object of oauth.OAuth and run some of it's methods. I replayed the code and then run the code to test. When verifying that the expectations matched the actual code, there was an issue. But what is the issue? It looks like this should work!

Luckily, in programming, there's often more than one way to do things. So, I tried a different approach. I rewrote my test as follows:

import hashtag

class HashtagTest():

  def testAuthorize(self):
    """Test the authorize method."""

    expected_auth_http = self.mox.CreateMock(httplib2.Http)

    mock_oauth = oauth.OAuth()
    self.mox.StubOutWithMock(mock_oauth, 'Flow')
    self.mox.StubOutWithMock(mock_oauth, 'Authorize')
    mock_credentials = self.mox.CreateMock(client.OAuth2Credentials)

    actual_auth_http = hashtag.Authorize()
    self.assertEquals(expected_auth_http, actual_auth_http)

At this point, the error changed:

Traceback (most recent call last):
  File ".../hashtag/hashtag_test.py", line 49, in testAuthorize
    actual_auth_http = hashtag.Authorize()
AttributeError: 'module' object has no attribute 'Authorize'

This error is much more clear; I've seen and dealt with this before. I looked at my import statements and the general structure of my code and found an easy solution:

My hashtag.py module was, in fact, in a directory titled hashtag (maybe poor naming on my part..). The import statement was importing the directory rather than the module. Therefore, I simply had to update my original code to the following in order for the test to work:

from hashtag import hashtag

class HashtagTest():

  def testAuthorize(self):
    """Test the authorize method."""

    expected_auth_http = self.mox.CreateMock(httplib2.Http)

    self.mox.StubOutClassWithMocks(oauth, 'OAuth')
    mock_oauth = oauth.OAuth()
    mock_credentials = self.mox.CreateMock(client.OAuth2Credentials)

    actual_auth_http = hashtag.Authorize()
    self.assertEquals(expected_auth_http, actual_auth_http)

This wasn't the only time the ExpectedMockCreationError error cropped up. In another test, I accidentally created a local variable called hashtag. Now, hashtag no longer referred to the module but the local variable.

In general, this error can happen for several reasons. One way to help figure out the problem is to rewrite the code as I did above - rather than stubbing out the entire class with mocks, create an instance of the class and stub out the methods.

Tuesday, November 27, 2012

Using python's virtualenv

I just finished writing a short demo application for Google Cloud Storage. To make installation of the demo easy, I wrote a setup script. Before sharing the code, I wanted to test this setup script to make sure it installs the correct packages and those packages work with my code.

My colleague suggested that I use python's virtualenv to do the testing. Doing some Google searches for virtualenv did not lead to any clear explanation of how to use it, so I thought I'd quickly jot down my own, basic experience with this tool.

(1) First, I installed virtualenv using the command:

pip install virtualenv

(2) Next, I set up a virtual environment:

virtualenv myenv

myenv, of course, can be replaced with any name you want. This command creates a directory called myenv in the current directory.

(3) To start using the new environment, I ran the following:

source myenv/bin/activate

Again, replace myenv with the name you gave your environment in step 2. After running the command, the shell indicates that I'm using myenv by adding myenv in parenthesis to the beginning of the prompt:


(4) Since I wanted to test my setup.py code, I then ran my setup script in this new environment. The setup script successfully installed all dependencies.

(5) Once setup was complete, I ran my code to make sure everything worked.

(6) Finally, after testing, I deactivated the environment by using the deactivate command:


Saturday, July 24, 2010

Python Library for Reading Excel Files

Came across a pretty sweet python library for reading data from Excel files: http://pypi.python.org/pypi/xlrd. Xlrd is super easy to install and use. Here's a snippet of code:
1:  import xlrd  
3: mybook = xlrd.open_workbook("test.xls")
4: sheets = mybook.sheets()
5: for sheet in sheets:
6: for i in range(sheet.nrows):
7: for j in range(sheet.ncols):
8: cell = sheet.cell(i, j)
9: if cell.ctype != xlrd.XL_CELL_EMPTY:
10: print cell.value

There are many other cool things you can do with xlrd. I encourage you to try it out!

Sunday, July 4, 2010

SEP a success!

For the past few weeks, I had been intensely preparing for a weeklong program for high school girls interested in computer science. I mentioned the program a couple times in past posts. I wanted to follow up now with a summary of week, including highlights and lowlights and lessons learned.

The program ran from Jun 28th to Jul 2nd. It started at 10am and went to 3pm every day, with an hour lunch break at noon. There were about 20 students in total, although some students had previous commitments and didn't make it every day.

Over the course of the week, we taught the students a variety of computer related topics. First, we started them off with a group exercise where they came up with an idea for a mobile app (exercise based on the Technovation Challenge). This exercise was designed to teach the students that applications don't start with coding. You first need an idea before you can start creating the app. The students worked for an hour on this task, then had the opportunity to present their idea to the rest of the group. The students came up with some really great products:

1. An app for learning more about colleges and signing up for newsletters, etc
2. An app for identifying what an animals body language might be telling you
3. [I can't remember this one, and it's the one that won! I'll figure it out soon and fill in this blank]
4. An app for allowing users to quickly jot down reminders and add the reminders to a calendar

The students then voted for the best app, and the group with the most votes got a prize (#3).

Next, we taught the students about computer architecture. We had about 6 computers set up that the students could take apart. We had worksheets with labeled pictures. I was surprised to find out that several of the students had already taken apart computers, and one had even built a computer from scratch! Students typically enjoy this exercise, since it's very hands on.

After computer architecture, we jumped into some python programming. We showed them some of the basics, including the infamous print "hello world" statement, data types, variables, and data structures. The students picked up on the concepts very quickly. They worked through exercises and seemed to understand the concepts really well.

After the intro to programming, we moved on to Computer Networking. This is usually one of the most popular lessons! As part of the lesson, we teach the students how to send email directly from the command line. This allows them to specify any sender email address, they'd like. :) This is fun for them, since they can send emails to friends from obama@whitehouse.gov or some other similar email address. They also learned about GET and POST, using GET directly from the command line.

Next, we taught them about databases and persistent data. They created tables in a database, added data to the table, and retrieved the data from the table, all using SQL! They even learned how to do joins, and were very curious, asking how to delete data and remove tables from the database.

With networking, databases, and programming under their belt, we introduced them to Google App Engine. Google App Engine allows users to create web applications very easily. We had developed a basic web app for them to build upon. The final product can be seen here: http://testingforsep.appspot.com. We choose the Outfit Builder app because it seemed like a product they could relate to. I know when I was a teen, I loved shopping and buying new clothes. We were assuming that teens haven't changed much over the years. :) As part of the intro to App Engine, I showed them how to create a basic application from scratch. They then practiced deploying an application to the Google servers.

Now that they understood how App Engine worked, we needed to teach them a couple more programming concepts before they could actually start filling in the missing pieces of the app. First, we taught them if statements. Once they understood if statements, they could build out the change background color portion of the site. Next, we taught them for loops. They could then display the bottoms on the page, and also work on the filtering form. We gave them a few other exercises to work on, including updating the database when a form was submitted on the Edit page and creating the random outfit. Overall, the students performed very well on all these exercises and finished them very quickly! In the future, I would prepare more advanced exercises for the students who were more advanced.

On Thursday, we gave the students a break and took them to the Intel museum. This turned out to be a lot of fun. Our tour guide was very knowledgeable and good with the students. We had a tour and also an activity called "Puzzle Ball" where the students had to write instructions for for to put together a puzzle. The students were allowed to keep the puzzles afterwards, which everyone was happy about. I would highly recommend the Intel museum tour to any school or summer program. It offers a great opportunity for students to learn more about computer processing.

Finally, we taught them about Android phone development and gave them access to App Inventor to create the basic HelloPurr application. App Inventor provides developers with a GUI interface that allows developers to drag and drop UI elements onto the phone screen, edit the properties of each element, then open another GUI application to add the functionality to each element. This portion, the Code Blocks editor, acts like a jigsaw puzzle. The students choose which element they want to add functionality to, then can select from different methods and outcomes, each fitting together like puzzle pieces. I was very impressed at how quickly the students picked it up!! The entire exercise was supposed to take about 1:30 in total. They finished in about 20 minutes!! Amazing. In fact, many of them even figured out how to add different things to the app, including changing the background color of the screen or changing the .wav file associated with the program. I was really impressed and am excited to see what Google does with App Inventor. I think it's a great tool for students to learn how to program the Android phone. In fact, I think it could be useful for everyone, kids and adults alike. I might even use it if I needed to create a basic Android app! Good work Google, keep innovating. :)

Overall, it was a great week. When the students were leaving, they were all smiles, which is always a good sign. A few things I learned from the program:

1. Prepare extra difficult material for those students who might outperform the rest
2. Have more lessons for App Inventor.
3. Go to the Intel museum again!
4. Give the students more opportunity to customize the App Engine application
5. Have backup material prepared in case something doesn't work correctly.

Thanks! If you're interested in learning more about the program, please feel free to contact me (kat.brisbin at gmail). You can also download most of the material at this website: http://cs.usfca.edu/~sep/calendar.html

Sunday, June 6, 2010

Python for Girls!

Hi all! I'm working on a new python tutorial for beginners, specifically aimed at girls. There aren't many of those out there yet, so I thought it would be a great opportunity to help start building the library! Here's a link to my documentation so far: http://docs.google.com/View?docID=0AQGjCIWYc3RlZGdoYjk0bnRfMTQwMmNtcTVrNmhm&revision=_latest&hgd=1. It's definitely a work in progress, but feel free to peruse the tutorial. If you notice any errors, feel free to comment!

What I think sets this tutorial apart from the rest is the writing style and approach to teaching. I'm writing the tutorial in a very comfortable and relaxed voice. I write what I would say if I was explaining python to someone in person, interjections and all. Hopefully this will make the tutorial more interesting and easier to read.

My approach to teaching is also different in that I provide concrete examples before explaining the programming concept. From what I've read (sorry, can't find the post anymore..), girls learn programming better when they first understand the problem at hand, then are taught how to solve the problem. I use this format frequently in my tutorial. For example, I first ask how lists are used in real life and provide some examples before even explaining what a python list is. This will hopefully help the girls realize that programming is about solving real life problems, such as creating the list of TV shows to display in the TiVo menu or creating an application to track your grocery list, and then teach them how to do so.

I'm hoping this approach will work well! I get a chance to test my material at the Summer Enrichment Program! If I have time, I will try to document my experience (what worked, what didn't) so that future tutorials can continue to improve!

Sunday, May 23, 2010

Android Unboxing

Having fun with Android today:

Wednesday, May 12, 2010

Creating an Android 'Library'

In some instances, you might want Android classes available to multiple Android applications. To simply add an Android project to the another Android project's build path will not work (a good explanation is here: http://groups.google.com/group/android-developers/browse_thread/thread/5537ae10e4143240). A workaround is summarized below:

1. Create a new Android project.
2. Add any necessary classes and interfaces (including AIDLs)
3. Allow the AIDLs to compile and generate Java code.
4. Update the .project file. This file is located in the root of the Android project. It contains the following contents:

1:  <?xml version="1.0" encoding="UTF-8"?> 
2: <projectDescription>
3: <name>[project name]</name>
4: <comment></comment>
5: <projects>
6: </projects>
7: <buildSpec>
8: <buildCommand>
9: <name>com.android.ide.eclipse.adt.ResourceManagerBuilder</name>
10: <arguments>
11: </arguments>
12: </buildCommand>
13: <buildCommand>
14: <name>com.android.ide.eclipse.adt.PreCompilerBuilder</name>
15: <arguments>
16: </arguments>
17: </buildCommand>
18: <buildCommand>
19: <name>org.eclipse.jdt.core.javabuilder</name>
20: <arguments>
21: </arguments>
22: </buildCommand>
23: <buildCommand>
24: <name>com.android.ide.eclipse.adt.ApkBuilder</name>
25: <arguments>
26: </arguments>
27: </buildCommand>
28: </buildSpec>
29: <natures>
30: <nature>com.android.ide.eclipse.adt.AndroidNature</nature>
31: <nature>org.eclipse.jdt.core.javanature</nature>
32: </natures>
33: </projectDescription>
Remove the following elements from the buildSpec:
1:   <buildCommand>  
2: <name>com.android.ide.eclipse.adt.ResourceManagerBuilder</name>
3: <arguments>
4: </arguments>
5: </buildCommand>
6: <buildCommand>
7: <name>com.android.ide.eclipse.adt.PreCompilerBuilder</name>
8: <arguments>
9: </arguments>
10: </buildCommand>
11: <buildCommand>
12: <name>com.android.ide.eclipse.adt.ApkBuilder</name>
13: <arguments>
14: </arguments>
15: </buildCommand>

Remove the following element from the natures:

1:   <nature>com.android.ide.eclipse.adt.AndroidNature</nature>  

5. Save the updated .project file.
6. Refresh the Android project in Eclipse.
7. Clean the project (select the project folder, select Project > Clean... from the main menu)
8. Remove the R.java file from the generated files.

Your project should now be ready to be added to the build path of other Android projects.