Packages using the behaving Python namespace

[ggozad]

Packages using the behaving Python namespace

[ggozad]

Hey!
Thanks for all the nice words:)
This looks very promising. I am currently away but back next week, in the meantime feel free to discuss here and involve others

[lampmantech]

I changed the project name to reflect the dotted namespace syntax:
https://github.com/lampmantech/behaving.cmd

Take a quick look at it if you could and see if the structure looks OK to you...

[ggozad]

The structure looks great!
Simplicity works for me, hence I chose a layout where I could easily find what I am looking for when my memory fails.
I would rephrase the steps so that for instance instead of:

Then Assert the file X exists

use:

Then the file X should exist

which makes for steps that can be read out aloud in spoken english in the spirit of BDD :)

[lampmantech]

Thanks.

I'll look again at the English, but the Assert actually came it from the equivalent
for directories, where I use Assert to throw an error if the directory doesn't exist,
and Ensure to create the directory if it doesn't exist. "should" doesn't capture the distinction. In the file case, Ensure that the file exists would be to create an empty file,
which is not in the steps but logically could be, rather than Assert which throws an error.

I've now done another more substantial behaving namespace package:
https://github.com/lampmantech/behaving.trytond

It's interesting in that you'll see an environment.cfg in the src/behaving/tests/features directory alongside the environment.pyto parameterize the steps.
This can be used to take the test suite and use it for a users their own end-use
without needing to change the steps code. I'll open another issue here for how
something like this will be needed by behaving to parameterize the arguments
to the browser instances that are created by splinter; e.g. caching in PhantomJS.

But in the meantime, on this behaving layout issue, the new package has brought to light the following suggestion: in your setup.py you have:

packages=find_packages('src', exclude=['tests']),

which would make me think that the code in src/behaving/tests should not get
installed into the site-packages Python module. (For me it does install them in,
but I think that's just a bug in setuptools, or in your call syntax.)

I think that it is good that the code in src/behaving/tests should NOT get
installed into the site-packages Python module, and seperates thetests/features
directory from the Python package installed code. This is epecially true when
people will be hacking on tests/features/environment.py and in my case
tests/features/environment.cfg - this should all be going on at their testrunner end,
not the Python module end.

If you agree with that point of view, then it seems logical to me that
src/behaving/tests should be moved to just tests, and the documentation adjusted
to elaborate on this distinction above. There's no Python reason I can see for it to be in
src/behaving/tests, and as they are tests of the installed package, one would
naturally look for them in tests.

Because of this distinction above it should not break anything for people in making this change - they're just have to simply adjust how or where they call behave.

[ggozad]

Re environmnet.cfg give me some time to take it in your other ticket. I am stumped with work and very slow at the moment apologies.

With regards to tests:
You are not supposed to import tests/features/enviioment.py. Instead you can import the top-level environment or the specific web/sms whatever environments. Perhaps I am missing something but I didn't quite understand why separating the tests from the src would be a good thing.

[lampmantech]

No hurry - I'm just trying to coordinate the stucture so that others will be in sync later.

You don't import tests/features/environment.py but behave does when it's run by the
client as a test runner. So moving src/behaving/tests to just tests emphasizes the distinction between what is installed by setup.py as a module, (i.e. everything in src) from
what the client runs with behave (which would be in just tests).

It fits in with the standard Python model of the tests being in tests, and emphasizing the distinction between what is installed from what is run after installation is good because the user running behave in tests can copy that tree to use as their starting point, where they will probably start pulling in other behaving.* into their environment.py .

It's not a big deal, and you have confirmed that there is not a good reason I had overlooked to keeping the tests down with the source code to the module. If you think of the process of an end user downloading and installing the software, then running the tests, then copying the tests directory to use as a starting point for his code, you should see what I'm driving at. Ans it's an easy change.

[ggozad]

I am still not sure I understand.
Typically we put tests together with source code to allow those who develop the package or want to verify that everything runs ok to run. In behaving in particular the package is under /src/. Everything on the root is buildout crap that is not installed.

When do the behaving tests run? For me they only run when I explicitly run them. Can you give me an example of how you run your testrunner that makes them run too?

The proposed workflow is to create a full behave structure as described in "Setting up a test environment" in the README. It does not involve the behaving tests in any way. I think it's a good idea to let the user import what they need from the various environments or import the whole lot from the behaving.environment.

/me is confused :)

[lampmantech]

Sorry for taking so much of your time on this, but I think you is confused :-)

"tests with source code to allow those who develop the package"
Yes but we usually don't install the tests with the module in lib/python2.7/site-packages/
and we really don't want to install feature files there, or tests/features/environment.py.

"In behaving in particular the package is under /src/"
Right, but conversely the things that won't be installed shouldn't be in src/.

"Everything on the root is buildout crap that is not installed"
Crap - not at all. Maybe that's where you're getting confused: some people put docs (hint hint :-) and docs are not crap! Most people put tests, which is my is point exactly.

I've refactored behaving.cmd into my proposed layout,
https://github.com/lampmantech/behaving.cmd
Note that behaving.cmd has no buildout crap - but it does have docs :-)

Look in the setup.py for my quick-n-dirty handler for setup.py test. In the proposed layout, you can do the canonical: git clone; cd; followed by

python setup.py install

which does not install the tests into lib/python2.7/site-packages/
Then you can do a canonical:

python setup.py test

which is the equivalent to the also canonical:

cd tests; behave ---stop features

Right now, if I copy your layout and setup.py which installs a module behaving.tests
into lib/python2.7/site-packages/behaving-*egg, then I will also have a module behaving.tests in my lib/python2.7/site-packages/behaving.cmd-*egg.
Then we both will be very confused, and python too. Better just you is confused :-)

Why this really matters is tests/features/environment.py which is really a template
for the end user to hack on and belongs away from the src code; i.e. in tests/!
Where it will get confusing for the end user is when he starts hacking on
environment.py to use multiple behaving.* modules. Whatever structure we use
should work well for an installation with multiple behaving.* modules installed.

[lampmantech]

I finally figured out a line in your setup.py:

packages=find_packages('src', exclude=['tests']),

You setup.py expects the tests to be in the root, like most other Python packages.
So all I'm asking is that the code structure conforms to your own setup.py (giggle).

PS: Why does your ReST formatting not work right when uploaded to pypi?
https://github.com/lampmantech/behaving.trytond/
I can't spot the reason.

[ggozad]

sure please make a PR, will accept immediately.
I've no idea about the rst.