1. Brodie Rao
  2. cram
  3. Issues
Issue #1 new

py.test integration as discussed on irc

Ronny Pfannschmidt
created an issue

stuff we just discussed on irc:

maybe split up later

  • bend that to py.tests tmpdir creation so the results end in one place (introspection of test created data on fail)
  • integration with py.test distribution mechanisms py.test -n 3 ... vs py.test --tx=ssh=somehost3 --tx=ssh=otherhost3 --tx=popen*3
  • reporting of the descriptive comments (cause its nice to get that in the failure report)

Comments (4)

  1. Brodie Rao repo owner

    I have a patch here that makes the API a little easier to use: http://bitbucket.org/brodie/cram-mq/src/tip/nicer-api (it depends on the runone patch). Let me know if you have any comments.

    Using cram.test() or cram.diff() means you have to do all the setup yourself. I don't know if this is necessarily a good thing. I think running tests from the API should have as close to the same behavior as possible that running the cram command does.

    I'm thinking I should make it possible to do the same tmp dir setup and environment cleaning with the API. Perhaps those can be moved into separate functions.

  2. Brodie Rao repo owner

    Thinking out loud:

    • We should think about how setup and teardown factors into the API, even if it isn't implemented right away.
    • We should make sure you can easily generate the same kind of reports with the API that cram itself generates. This might already be the case, I'm not sure.
    • I'm not entirely sure how you'd get it to report what part of test an error occurred in. I don't really like the idea of making comments anything more than text that cram ignores. Maybe you could figure out this information yourself based on the line numbers in the diff hunks. Or cram could include a portion of the previous comment at the end of the hunk header (like diff -p).
  3. Log in to comment