Minor feedback
Chuck Esterbrook
is some minor feedback on the product:
-- At http://pypi.python.org/pypi/pythoscope/0.3 I think this line:
$ cat .pythoscope/points-of-entry/123_years_old_python.py
is supposed to be:
$ cat > .pythoscope/points-of-entry/123_years_old_python.py
-- When Pythoscope generates:
def test_foo(self):
assert False # TODO: implement your test here
I think it should include the method sig:
def test_foo(self):
# def foo(self, x, y)
assert False # TODO: implement your test here
This would be especially handy when creating unit tests for code bases
written by others.
-Chuck
--
http://cobra-language.com
Michał Kwiatkowski
<Chuck.Es...@gmail.com> wrote:
> -- At http://pypi.python.org/pypi/pythoscope/0.3 I think this line:
> $ cat .pythoscope/points-of-entry/123_years_old_python.py
> is supposed to be:
> $ cat > .pythoscope/points-of-entry/123_years_old_python.py
The tone of the whole tutorial is from the point of view of an
observer, so we pretend the user already has this code in there and we
just peek into it for the details. So for me it makes sense to leave
it as "cat .pythoscope/points-of-entry/123_years_old_python.py". If we
change it, we would probably have to change all of the other calls to
cat as well. Do you think it's confusing to have actual commands to be
executed by the user (e.g. "pythoscope --init") and those cat commands
interleaved? Maybe we should just drop the "cat" thing and list file
contents after the file name?
> -- When Pythoscope generates:
>
> def test_foo(self):
> assert False # TODO: implement your test here
>
> I think it should include the method sig:
>
> def test_foo(self):
> # def foo(self, x, y)
> assert False # TODO: implement your test here
Good idea! This way developer won't have to go back to the code the
first time he looks at those stubs. I think we may go even further
with this and include object creation and assertion stubs for all test
methods. For example:
class TestSomething(unittest.TestCase):
def test_some_method(self):
# something = Something(x, y)
# self.assertEqual(<expected value>, something.method(<a>, <b>, <c>))
assert False # TODO: implement your test here
Any comments on that?
> This would be especially handy when creating unit tests for code bases
> written by others.
Agreed. Thanks for your input!
Cheers,
mk
Chuck Esterbrook
<consta...@gmail.com> wrote:
...
> cat as well. Do you think it's confusing to have actual commands to be
> executed by the user (e.g. "pythoscope --init") and those cat commands
> interleaved? Maybe we should just drop the "cat" thing and list file
> contents after the file name?
When I saw the other commands that I was supposed to enter in order to
take actions, I took "cat" the same way--that something was being
created/done. But put that aside for a moment, because another
consideration is that Windows users won't even have "cat" (unless they
have cygwin or similar utils installed). As you speculated, just
listing the file contents might be best. After all, Unix-heads already
know how to use "cat".
...
> class TestSomething(unittest.TestCase):
> def test_some_method(self):
> # something = Something(x, y)
> # self.assertEqual(<expected value>, something.method(<a>, <b>, <c>))
> assert False # TODO: implement your test here
>
> Any comments on that?
Yeah, anything that can cut down on the amount of head scratching to
get a test going would be great. It will probably take some
experimenting to figure out exactly what to provide.
>> This would be especially handy when creating unit tests for code bases
>> written by others.
>
> Agreed. Thanks for your input!
No problem. Thanks for your efforts,
-Chuck
--
http://cobra-language.com/