when run on a directory the tappy cli tool expects all files in a directory to be tap files and will fail otherwise

[cj-timothy-sampson]

This makes it more painful to use than needs be in the case where one has a single "reports" dir that contains files of many types (junit xml files, tap files and whatever else)

$ tappy .
......
----------------------------------------------------------------------
Ran 6 tests in 0.000s

OK
$ cat *
1..3
ok 1 - Input file opened
ok 2 - First line of the input valid
ok 3 - Read the rest of the file
1..3
ok 1 - Input file opened
ok 2 - First line of the input valid
ok 3 - Read the rest of the file
$ ll
total 136
drwxrwxr-x  2 tsampson tsampson   4096 Jun 22 10:59 .
-rw-rw-r--  1 tsampson tsampson    100 Jun 22 10:59 2.tap
-rw-rw-r--  1 tsampson tsampson    100 Jun 22 11:02 1.tap
drwxrwxrwt 36 root     root     122880 Jun 22 11:09 ..
$ touch random.junit.xml
$ tappy .
......F
======================================================================
FAIL: <file=./random.junit.xml>
Missing a plan.
----------------------------------------------------------------------

----------------------------------------------------------------------
Ran 7 tests in 0.000s

FAILED (failures=1)

Arguably tappy shouldn't be trying to parse an xml file as a tap file. One could argue that the user should filter non-tap-files out but this makes calling tappy with a dir less useful than it might otherwise be.

[cj-timothy-sampson]

Seems like this might be rather simple to fix by just globbing over *.tap here:

tappy/tap/loader.py

Line 59 in 0c38a48

def _find_tests_in_directory(self, directory, suite):

?

[mblayman]

Thanks for the report, @timsampsoncujo! This is an interesting case that I'm not sure how to handle.

I try my best to implement this library according to the TAP spec. There is nothing in the spec that says that a TAP file ends with .tap (there is also no MIME type on the official Media Types list). I think it would be an overreach to filter on files that look for that filename pattern.

The workaround solution would be to run:

$ tappy *.tap

I think a likely solution would be to opt out of the parsing errors as described in issue #39.