Running Nosetest on Ex47?

hi, running into problems using nosetest for ex47… in my terminal my error message says " no module named"
thanks Rick

1 Like

Do you have your code in a file named:
Try: import Ex47
I guess there is a function ”def game():” ?
Perhaps this works: ” from Ex47 import game”

1 Like

Hi, thanks for the advice , I do appreciate it .
I have 3 files within ex47. They are , and
These 3 files were given as part of the chapter 47.
I am supposed to be able to run ‘nosetests’ and get 3 tests with no fails.
The 2nd line in says "from import Room.
When I place your suggestion within I got this error message : “ImportError: No module named ex47”
No success yes but I would appreciate your help, thanks

Hello again.
I think it should be:
”import game” then.
I have: ”from Rooms import Room” because my file is called and I import a class named Room. This is for Pytest.
But I think this part is the same for nosetest.
Perhaps you also could try: ”from game import (the name of your first class in game).

1 Like

Thank you very much ! I was really stuck here and you fixed it for me. You were very helpful!!!
Im almost done this one and on to ex48 :slight_smile:
Best regards ,

1 Like

Also, sometimes you have to force the PYTHONPATH to the local directory. On Linux/OSX it’s like this:


On windows this doesn’t come up as a problem that often, but let me know if you need that line too.

I had no end of trouble. I could not get the three tests to work in Ex47. The problem was simple in the end and I found it while watching your video. At one stage I saw the file in the Ex47 directory, that’s what it says right? It kept failing over and over (I kept getting ran 0 tests) and I typed in all the code a few times. Then while watching the video I saw your location for was ex47/ex47/
No problems now. I thought changing the master directory to something else would maybe ease the problem.

1 Like

Hmmm, yes I think I cover it but whenever you code python you stay above your code. So let’s say you have a file like:


The mistake people make is they do this:

cd ex47

That fails because all of your code talks about ex47 being a module. Like this:

from ex47 import game

That means your code thinks you’re above, hanging out so you can see ex47. So to solve it, do this:

cd …

If you don’t see ex47/ then you’re not in the right place. Then do this:

ls ex47/

If you can’t do that you aren’t in the right place. Once you can then you’re ready to go.

Thanks for the reply Zed.

It was a silly error, easy to make. Just thought if anyone else was struggling it might help.

I’m curious, why does my nosetest succeed running from the top-level directory, but the test code fails when run from tests/? ls ex47/ works.

Directory structure:

  • bin/
  • docs/
  • ex47/
  • tests/

Import statement in
from import Room

when running python from tests/:

Traceback (most recent call last):
  File "", line 2, in <module>
    from import Room
ModuleNotFoundError: No module named 'ex47'

It looks like you might not understand how modules relate to files. When I do this in python:

from ex47 import game

Python starts in my PYTHONPATH (do echo $PYTHONPATH on Linux/OSX) and searches for a file that is:


Now, let’s say you cd down into tests/ but your PYTHONPATH only has . in it because you did:


Well, python will look for these files from the tests/ directroy, so it’s kind of looking for:


Make sense?

Unfortunately, I still don’t understand how modules relate to files.

Is the PYTHONPATH represented by . in this case the top-level ex47/ ? Or is it my home directory?

Running export PYTHONPATH="${PYTHONPATH}:/hard_way/projects/ex47"
in Terminal results in no errors on from import Room, but it doesn’t run anything either. Nosetests are still fine.

When I move the file into tests/, from import Room doesn’t find the module.

from import Room doesn’t work either.

Neither does renaming the file and moving it to tests/, then calling it by from ex47.game_tests import Room

The “.” means this directory. So export PYTHONPATH=. really means export pythonpath from here (wherever you run it from).

To be honest I recall having issues with Nose around this point and shifted to PyTest as I find it simple.

I remember I struggled with the same problem for some hours then I did ex47. I looked how I did it. I have the import in stated like this:

from import Room

My directory structure:

|-- ex47_container
|    |--bin
|    |--docs
|    |--ex47
|    |    |
|    |    |
|    |--tests
|    |    |
|    |    |
|    |
|    |

It asumes that you are running your script from within the directory ex47_container like this:

$ pwd
> some_path/ex47_container
$ nosetests3 tests/ 

So nosetests takes ex47_container as your “home” directory and then it calls the tests/ file it sees that the ex47 directory (that with the and the files in it) is on the same level as tests so it can then grab the right file with the from import Room command.

Imagine nosetests is a person and you are that person. You then have always a relative position to some fixed objects around you. Imagine you are in your apartment. The structure of your home is always the same (hopefully) but when you moving through your home the path to the different rooms always change. When you are in the kitchen you might to have to go to the left when you want to go to the living room but when you are in your bedroom you might to have to go to the right to reach your living room. When you call Python from a specific directory (or set your PYTHONPATH to a specific directory) you say Python where it is in the apartment. So you always have to give it the Path that is “relative” from the directory Python (or nose) is called. Normally that would be the home directory of your program, like ex47_container in my case.

I like to draw diagramms, so here it is one:

As you can see, your PATH to the moduls (everything with a in it is recognised as a module) depends on the position you (or python or nose) is in. If you call ex47 from the corridor, the path is go to ex47 if you are in tests the path is first go to corridor then to ex47.
Hope that helps.


It’s so simple you’re just over thinking it. First we have to define two types of . (dots):

  1. PYTHONPATH=. <— this means “tell python to look for code in the current directory”. That’s all, and has nothing to do with the dot.
  2. <-- This acts as a separator for nested modules. I could have It’s exactly the same as having an object and doing obj.attr, like in monster.kill().

The first PYTHONPATH=. is for your bash shell. Set that then forget about it.

The second . means get. It only ever means get. That is all it will ever mean ever. This is where everyone overcomplicates things, so get this burned in your brain: is the equivalent of ex47[‘game’], you are simply telling python “get ex47, AND THEN, get the attribute named ‘game’ from it.” Every dot does an AND THEN get. So if I have this:

It can be read as:

“Python, get ex47 AND THEN, get game from that, AND THEN, get player from that, AND THEN, get Monster from that.”

Ok, so how does that map to files? Every . maps to either a directory or a .py file.

ex47/  <-- ex47  . <-- game

You can think of the . as a / in a way. Now, what about that .player.Monster part I’m making up (that’s not really in your code)? That would be variables or objects inside your file:

ex47/ <-- ex47 . <-- game .
      player  <-- some variable in
          Monster <-- some class in the player

But, I could also do those like this:

              class Monster

Now, your next move is to actually play with this rather than trying to read my description and figure it out intellectually. Experimentation is the way to go on this. Make some diretories, put .py files in there, put ````` files in there. Put code in the .py files. Try different ways to use . to get at the code in the files.

Remember . is kind of mapping to the / in a path: <----> ex47/

I think I’m starting to understand. from import Room throws no Tracebacks when run from the top-level ex47/ as python tests/ It still doesn’t run any program, but at least there’s no errors. I’m guessing at this point my problem is not having a complete program capable of running anything, rather than a bad directory/module structure.

1 Like

Ok, if you can get your code into then I can pull it and see what’s going on. Also, post a screenshot of your terminal at the point where you have an error.

Code here

As mentioned above, there is no error message when the nosetests pass. The program just doesn’t run:

Yes, it does work. Your tests ran. You see that line that states “Ran 3 tests in 0.004s”?

If you see something like that, when you know that everything works as expected. Try to change something in your tests so that it fails. And one of your tests should turn red.

But you can move forward now, everything is good :slight_smile:

1 Like

Ok, so I think I mentioned this before, but your tests need to be run in a special way. So when you do this:

python tests/

Why do you think it should “run”? Technically it did run. Python loaded it, setup all your functions, and since you didn’t tell python to do anything with those functions it quit. Look in the file. Where do you actually have code that calls those functions?

What nosetests does is it loads these test files, just like python, but it knows how to run the tests specially for you and print out messages and errors. So, your tests are running fine, and now you have to do some mental work:

You seem to have a misperception of what happens in a .py file when you define functions. You have to sit down and ask yourself, “Why did I think would run? What does run mean? Why didn’t it run?”

Reply back with your answers as I’m curious.