Unable to use inclusive tags on Aloe v0.1.12

[brarcher]

One feature that Aloe has over Lettuce is its sensical usage of tags. Namely, I would like to use tags to both include and exclude tests, and the documentation suggests that Aloe provides this.

However, I've not been able to get the simplest example of tagging to work with Aloe v0.1.12. (Note though that aloe --version reports aloe version 1.3.7 which is confusing). The following is my example project:

|-- features
   |-- __init__.py
   |--VerifySetup.feature
   |-- steps
      |-- __init__.py
      |-- steps.py

And the contents:

steps.py:

from aloe import step

@step(r'^Given this step was executed')
def verifySetup(step):
    #If we get here then all is well
    assert True

VerifySetup.feature:

Feature: Test that aloe is setup and running correctly

    @verifysetup
    Scenario: Verify Setup
        Given this step was executed

Aloe will run the feature in question if I specify it directly:

$ aloe features/VerifySetup.feature  -v
Verify Setup (features.VerifySetup: Test that lettuce is setup and running correctly) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.002s

OK

However, if I tell aloe to run based on a tag it will run nothing:

$ aloe -a verifysetup -v

----------------------------------------------------------------------
Ran 0 tests in 0.003s

OK

Is there something that my example is doing incorrectly? The Aloe and Nose documentation makes it appear that one can use tags in this way.

[brarcher]

In case it is helpful, here were the dependencies I needed to install in order to satisfy aloe and its dependencies:

aloe 0.1.12 future 0.16.0 gherkin 4.0.0 nose 1.3.7 pluggy 0.3.1 Pygments 2.1.3.bb pylint 1.6.4 repoze.lru 0.6 tox 2.3.1 virtualenv 15.1.0

[koterpillar]

Just to check, is the test run with just aloe -v?

[brarcher]

The test is run:

$ aloe -v
Verify Setup (features.VerifySetup: Test that aloe is setup and running correctly) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.007s

OK

[koterpillar]

I can't reproduce this. Here's what I have:

$ python --version                                                                   
Python 3.5.2
$ pip freeze      
aloe==0.1.12
blessings==1.6
future==0.16.0
gherkin-official==4.0.0
nose==1.3.7
repoze.lru==0.6
$ ls -R
.:
features

./features:
__init__.py  __init__.pyc  __pycache__  steps  VerifySetup.feature

./features/__pycache__:
__init__.cpython-35.pyc

./features/steps:
__init__.py  __init__.pyc  __pycache__  steps.py  steps.pyc

./features/steps/__pycache__:
__init__.cpython-35.pyc  steps.cpython-35.pyc
$ cat features/VerifySetup.feature
Feature: Test that aloe is setup and running correctly

    @verifysetup
    Scenario: Verify Setup
        Given this step was executed
$ cat features/steps/steps.py
from aloe import step

@step(r'^Given this step was executed')
def verifySetup(step):
    #If we get here then all is well
    assert True
$ aloe -a verifysetup -v
Verify Setup (features.VerifySetup: Test that aloe is setup and running correctly) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.004s

OK

Same result observed with Python 2.7.13.

Can you perhaps upload an archive with your file tree, or reproduce this on Travis CI via an Aloe branch or a standalone project?

[brarcher]

I am not sure the difference, but now when I attempt to reproduce the issue it is working as expected, namely:

$ aloe -v
Verify Setup (features.VerifySetup: Test that aloe is setup and running correctly) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.007s

OK
$ aloe -a verifysetup -v
Verify Setup (features.VerifySetup: Test that aloe is setup and running correctly) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.008s

OK
$ aloe -a \!verifysetup -v

----------------------------------------------------------------------
Ran 0 tests in 0.006s

OK

It is unclear what I might have done incorrectly before. However, there does not seem to be an issue. Sorry for the trouble, please disregard.