Not sure I'm doing Ex 47 the right way

Python
#21

That seems to work better however still can’t get it to test.
I still just run with pytest in the directory above my test folder?

(lpthw) Kims-MBP:ex48 trager$ ls
bin		docs		ex48		setup.py	tests
(lpthw) Kims-MBP:ex48 trager$ pytest
============================= test session starts ==============================
platform darwin -- Python 3.6.0, pytest-5.3.5, py-1.8.1, pluggy-0.13.1
rootdir: /Users/trager/python/projects/ex48
collected 0 items                                                              

============================ no tests ran in 0.01s =============================
(lpthw) Kims-MBP:ex48 trager$
#22

Yes, that should work. Can you show us the contents of the test folder and one of the test files?

#23

My test file tests/ex48_tests.py

import pytest
from ex48 import lexicon


def test_directions():
    #Need to be able to feed in a strings, then check check it to see if it's a direction
    assert_equal(lexicon.scan('north'), [('direction', 'north')])
    result = lexicon.scan('north south east')
    assert_equal(result, [
    ('direction', 'north'),
    ('direction', 'south'),
    ('direction', 'east')
    ])

def test_verbs():
    assert_equal(lexicon.scan("go"), [('verb', 'go')])
    result = lexicon.scan("go kill eat")
    assert_equal(result, [
    ('verb', 'go'),
    ('verb', 'kill'),
    ('verb', 'eat')
    ])

def test_noun():
    assert_equal(lexicon.scan('bear'), [('noun', 'bear')])
    result = lexicon.scan('bear princess')
    assert_equal(result, [
    ('noun','bear'),
    ('noun','princess')
    ])

def test_numbers():
    assert_equal(lexicon.scan("1234"), [('number', 1234)])
    result = lexicon.scan('3 9135435')
    assert_equal(result, [
    ('number', 3),
    ('number', 9135435)
    ])

def test_errors():
    assert_equal(lexicon.scan('asdased'), [('error', 'asdased')])
    result = lexicon.scan('Bear isa princess')
    assert_equal(result, [
    ('noun','bear'),
    ('error', 'isa'),
    ('noun','princess')
    ])

def test_stop():
    assert_equal(lexicon.scan('the'), [('stop', 'the')])
    result = lexicon.scan('the in of')
    assert_equal(result, [
    ('stop','the'),
    ('stop', 'in'),
    ('stop','of')
    ])

test folder:

$ ls tests

__init__.py 
__pycache__ 
ex48_tests.py 
parser_tests.py
#24

@ktrager in Pytest you need to prefix the file with test rather than suffix. So parser_tests.py needs to be renamed test_parser.py.

I think it will find tests or test iirc. To be honest this is a much tidier way to see all the test files in a directory anyway.

1 Like
#25

Yes, and I think you need to use plain assert statements instead of assert_equal etc. See here.

2 Likes
#26

Oh yes totally. I assumed he’d be rewriting the tests using the more simple syntax too.

I strongly recommend Python Testing with Pytest too if you really get into using it.

https://www.amazon.co.uk/dp/1680502409/ref=cm_sw_r_cp_awdb_t1_VYfoEb8HCERQ3

1 Like
#27

I saw this book mentioned over and over again, i’ll put it on my list.
It seems that testing is a very good habit to get into early.

#28

Ahhh - yeees, I did actually read that, but for some reason did not actually implement.

#29

I’m somewhat bias on that subject but yes, building testing at a unit level into your coding practices early is a good thing.

1 Like
#30

You know, I really dislike writing tests. It’s repetitious and messy at the same time. BUT it saves you so much headache later! It’s a bit like tooth brushing… do it twice a day or end up in agony eventually.

1 Like
#31

Absolutely, and if you comment your code and tests well, its a great reminder of what you were actually doing in the code, months after you’ve totally forgotten.

1 Like
#32

Have you tried TDD @florian ? Perhaps adding the test part into the dev flow might make it less horrendous. Probably not, but its a way to address that in your flow. We’ve discussed it with Zed a few times and he convinced me that a pure ‘test-first’ approach is too mechanical and not how developers/artists work in real life. Somewhere between red/green/refactor and no-tests until afterwards, is a good iterative approach.

1 Like
#33

Definitely. Another way to look at it is, start with what you are clearest on in your mind.

If you know how the interface should kind of look/work, but not really what goes inside it, then starting with the test makes sense. Or, if you’ve written this very same thing a billion times before.

If you have more of an idea how the the functions/thing should work, but not really how to interface with it, then start with code and build up the tests as you go.

Incidentally, nobody actually does test first. What they do is:

  1. Spike <— that’s code that basically figures out a hack without tests.
  2. Tests <— where test first nazis think they start.
  3. Code <— this is just like a spike but now it has tests.
#34

Thanks, @gpkesley. Actually, I read about TDD but it all seemed a tad too messianic for my taste. What I do like to do is drafting a few tests in advance as a means to figure out the interface. But I usually don’t make them run at all costs until I have at least some functionality ready.