Join us and get access to hundreds of tutorials and a community of expert Pythonistas.

Unlock This Lesson

This lesson is for members only. Join us and get access to hundreds of tutorials and a community of expert Pythonistas.

Unlock This Lesson

Hint: You can adjust the default video playback speed in your account settings.
Sorry! Looks like there’s an issue with video playback 🙁 This might be due to a temporary outage or because of a configuration issue with your browser. Please see our video player troubleshooting guide to resolve the issue.

Writing Your First Test & The Core TDD Cycle

Give Feedback

After setting up the project, you’ll now write your first unit test and learn about the core TDD cycle.

Comments & Discussion

Dan Bader RP Team on March 13, 2019

@Elie: Thanks for your question. Our video lessons are only available for streaming at the moment.

Elie Kawerk on March 13, 2019

Thanks @Dan, is the material covered in the video available on Github?

BTW, I like the revamped real-python platform a lot!

Dan Bader RP Team on March 13, 2019

Not right now but that’s a great idea, we can definitely put the sample code up on GitHub and then link it from here :)

Vikram Kalabi on March 18, 2019

Could you please share information on your Visual Studio theme and setup? Looks wonderful!

Dan Bader RP Team on March 18, 2019

@Vikram: Here they are—

The theme is Monokai Pro. www.monokai.pro/vscode/

I use either Dank Mono or Operator Mono. dank.sh www.typography.com/fonts/operator/styles/

I copied this from one of Chyld’s comments on another video in this series.

Grant King on March 20, 2019

That import line gives me an error with this file structure, but everything works if I move test_stack.py directly under the DS folder. Is there a better way to make it work?

Vanam on April 12, 2019

Nice tutorial, terminal that is used is it ZSH?

adoormouse on Sept. 10, 2019

Had issues with running pytest with this setup. Got it working with:

test_stack.py
from ds import Stack
...

(venv)$ python -m pytest tests/

AugustoVal on Sept. 18, 2019

Quick question - I am getting this message trying to run Pytest

AVal-iMac% python -m pytest -v
/usr/bin/python: No module named pytest
AVal-iMac% python3 -m pytest -v
/usr/local/bin/python3: No module named pytest

I have the package installed according to my list.

AVal-iMac% pip3 list           
Package            Version   
------------------ ----------
pytest             5.1.2     
pytest-cache       1.0       
pytest-pep8        1.0.6 

Any subjection why it is not working for me? I already un-installed and re-installed but is not working.

Thanking you in advances for your help

Dan Bader RP Team on Sept. 18, 2019

@AugustoVal, try running the pytest command directly like so:

pytest -v

Dri on Oct. 2, 2019

I’m getting the following error when running pytest:

ImportError while importing test module '/test-driven-dev/tests/test_stack.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
tests/test_stack.py:1: in <module>
    from ds.stack import Stack
E   ModuleNotFoundError: No module named 'ds'

My directory schema:

test-driven-dev ]$ tree
.
├── ds__.py
   └── stack.py
└── tests
    ├── __pycache__
       ├── test-stack.cpython-37-pytest-5.2.0.pyc
       └── test_stack.cpython-37-pytest-5.2.0.pyc
    └── test_stack.py
   ├── __init

Any one gone through this?

przemodev on Nov. 20, 2019

I believe that saying that a single underscore makes variable private and protects from accessing the value directly does not make any sense. Would rather say that __var makes the variable somewhat private i.e: not accessible by just a . notation on the object (__var is called _ClassName__var instead and . accessible anyway).

Christopher Lee on May 5, 2020

Never in the history of forever has anyone ever picked such a terrible font to due a coding tutorial, it’s like a horrible Walt Disney style of text that I cannot read…

subonlinetmp on July 29, 2020

@Dri Yes, me too if I try just pytest -v (Though your problem may be that __init.py__ should be in ds/ not tests/ – as ds is meant to be the package from which one can import the module stack with the Stack class. However, supposedly in Python 3.3+ __init.py__ is no longer required…but, maybe you’re running an earlier version and this causes ds to not show up as a package for you?)

@Dan Bader First off, I don’t understand why we’re not running pytest directly as you suggest (i.e. why he’s using python -m pytest -v to start with, instead of just pytest -v as you suggest)…?

Indirectly, maybe this is why: When I attempt to run pytest directly, I get the same error @Dri reported:

12:08 ~/src/python/examples/tdd} pytest -v
============================= test session starts =============================
platform darwin -- Python 3.8.2, pytest-5.4.3, py-1.8.1, pluggy-0.13.1 -- /Library/Frameworks/Python.framework/Versions/3.8/bin/python
cachedir: .pytest_cache
rootdir: /Users/rich/src/python/examples/tdd
plugins: cov-2.10.0
collected 0 items / 1 error                                                   

=================================== ERRORS ====================================
____________________ ERROR collecting tests/test_stack.py _____________________
ImportError while importing test module '/Users/rich/src/python/examples/tdd/tests/test_stack.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
tests/test_stack.py:1: in <module>
    from ds.stack import Stack
E   ModuleNotFoundError: No module named 'ds'

My import is same as in the course:

from ds.stack import Stack

My file structure is also the same:

12:08 ~/src/python/examples/tdd} tree
.
├── README.txt
├── README.txt~
├── ds
   ├── __init.py__
   ├── __pycache__
      ├── stack.cpython-38.pyc
      └── test_stack.cpython-38-pytest-5.4.3.pyc
   ├── stack.py
   └── stack.py~
└── tests
    ├── __pycache__
       └── test_stack.cpython-38-pytest-5.4.3.pyc
    ├── test_stack.py
    └── test_stack.py~

I’m glad about this error, actually, as it points out something I don’t understand, but feel is important: I’d like to understand how the import is searching for the ds module in general, and why it’s not finding it with “pytest”, but does find it with python -m pytest…?

From web sleuthing, I’ve read that the latter adds CWD to sys.path. But, I still don’t see how it all fits and why one works and the other doesn’t? Why would it need to add CWD to a path when I’m running from that same dir? Is it searching from tests/ since it finds test_stack.py there, but no ds/ subdir in tests/?

To test that, I tried adding CWD to --rootdir, but got the same error:

01:15 ~/src/python/examples/tdd} pytest -v --rootdir=$HOME/src/python/examples/tdd/
============================= test session starts =============================
platform darwin -- Python 3.8.2, pytest-5.4.3, py-1.8.1, pluggy-0.13.1 -- /Library/Frameworks/Python.framework/Versions/3.8/bin/python
cachedir: .pytest_cache
rootdir: /Users/rich/src/python/examples/tdd
...
tests/test_stack.py:2: in <module>
    from ds.stack import Stack
E   ModuleNotFoundError: No module named 'ds'

…so, I added an assert to test_stack.py to check sys.path and found that, sure enough, the difference is that CWD = /Users/rich/src/python/examples/tdd on the sys.path (and that --rootdir=$HOME/src/python/examples/tdd/ does NOT add it to sys.path!!)

via python -m pytest -v:

sys.path = ['/Users/rich/src/python/examples/tdd/tests', '/Users/rich/src/python/examples/tdd', '/Library/Frameworks/Python.framework/Versions/3.8/lib/python38.zip', '/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8', '/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/lib-dynload', '/Users/rich/Library/Python/3.8/lib/python/site-packages', '/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages', '/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/gnureadline-8.0.0-py3.8-macosx-10.9-x86_64.egg']

via pytest -v: and pytest -v --rootdir=$HOME/src/python/examples/tdd/:

sys.path = ['/Users/rich/src/python/examples/tdd/tests', '/Library/Frameworks/Python.framework/Versions/3.8/bin', '/Library/Frameworks/Python.framework/Versions/3.8/lib/python38.zip', '/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8', '/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/lib-dynload', '/Users/rich/Library/Python/3.8/lib/python/site-packages', '/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages', '/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/gnureadline-8.0.0-py3.8-macosx-10.9-x86_64.egg']

So, I’m at a loss to figure out just what’s going on here (unless there’s a bug in pytest --rootdir), nor how to get pytest to work directly as suggested…

[ other than this symlink hack in tests/:
01:29 ~/src/python/examples/tdd/tests} ls -l ds
lrwxr-xr-x  1 rich  staff  5 Jul 29 01:28 ds@ -> ../ds
]

I’d really appreciate some help with this!!

subonlinetmp on July 29, 2020

PS. After reading docs.python.org/2/tutorial/modules.html#the-module-search-path, I found that this also allowed pytest -v to work (ie, find the ds.stack module):

01:35 ~/src/python/examples/tdd} export PYTHONPATH="$HOME/src/python/examples/tdd/"

But, that also seems like a hack: In order for this to work automatically, we’d need to be setting PYTHONPATH every time we change directories!

Why doesn’t pytest just include CWD by default? Why doesn’t --rootdir=CWD work either?

(Maybe the author’s already been down this path!? All the sudden python -m pytest isn’t looking so bad! :)

Become a Member to join the conversation.