• Frist (unregistered)

    Frist

  • Quamrana (unregistered)

    If they never called that particular method, then it could have been omitted. If all the methods could be omitted, then the whole class could be omitted.

  • giammin (unregistered)

    abstract Frist

  • Hanzito (unregistered)

    I can already imagine the architectural requirement that all test members must call the inherited, "super" function too.

  • BOFH (unregistered)

    I'm not brillant at this like some, but if it's just an intermediate abstraction-layer where there is no point to duplicate a thorough test that has already been implemented in the lower layers, maybe the guy just wanted to get his test coverage to 100% by adding these stubs at the dummy layers?

  • Carl Witthoft (google)

    I'll never look at my Abstract Algebra textbooks the same way again.

  • Dude (unregistered) in reply to BOFH

    Except code coverage generally doesn't count unit tests, and unless the method actually called real code, it wouldn't contribute to the coverage anyway. Also, in unit tests, you shouldn't be traversing 'layers' - anything outside of the method you are testing should be mocked, so there shouldn't be any kind of duplication (unless you're testing the same thing in a different method).

    Integration testing, on the other hand...

  • Black Mantha (unregistered)

    TestDriverAbstract: see it a text is a summary for a driver AbstractTestDriver: an abstract class for drivers you want to test DriverTestAbstract: abstract all the tests from a driver DriverAbstractTest: test if a driver class is actually abstract

  • Jajcus (unregistered)

    And even the code is wrong. 'pass' is a perfectly valid 'no-op' implementation.

    In Python, 'no implementation' would be one of the three (depending on context):

    1. no method defined
    2. a method that just raises a NotImplementedError exception
    3. a method that just returns the NotImplemented value
  • Jajcus (unregistered)

    oh… I meant 'comment' no 'code'…

  • Uhm (unregistered)

    ok, but for truely "abstract" classes, really you should raise NotImplementedError

  • Sole Purpose of Visit (unregistered)

    For what it's worth, if you want a true ABC in Python, you can ... shudder! ... take advantage of the language facilities to do so. These are both built-in to the language (as of 2.6 or so) and supported by libraries.

    Just google "stack overflow abstract base class python." You're going to need a meta-class and a decorator, but hey, this is how Python does it.

    (And, oddly enough, it's a mechanism that is implemented very much in terms of OO Inheritance, so I'm not entirely sure what Remy's general complaint is here.)

  • foxyshadis (unregistered) in reply to Jajcus

    And if you actually are writing a pure abstract function, you should raise NotImplementedError instead of pass anyway. This does absolutely nothing to keep someone from forgetting to implement the function, it'll just silently do nothing and return when the real object is one particular type, and you'll hate life until you stumble onto the problem.

  • Sole Purpose of Visit (unregistered)

    Not sure how to append a "I didn't think about this clearly enough" addendum to a comment "held for moderation," so I'll just add that Python ABCs do, indeed, use pass when properly implemented. I suppose they could raise an exception too, but that wouldn't be very Pythonic ... because the whole point of an ABC, as a general CS category, is that it cannot be instantiated. Consequently, in Python, you import the relevant module, you add the relevant decorator, and -- on the principle of Least Surprise -- you find that your ABC will not compile.

    So, in fact, the OP code is about half-way there. (OK, it doesn't abstract very much. But, y'know, YAGNI and TDD and stuff. I don't see any reason to complicate the ABC prematurely, based upon the info provided.)

    Add an import and a decorator, and you're there!

  • siciac (unregistered)

    Object-oriented languages promise a lot of code-health benefits, and [if] used properly, they can certainly deliver.

    Sure, quoth chapter 3 of Effective Java, something as simple as "equals" is broken if you use inheritance:

    It turns out that this is a fundamental problem of equivalence relations in object-oriented languages. There is simply no way to extend an instantiable class and add an aspect while preserving the equals contract. There is, however, a fine workaround.

    That's not peculiar to Java, either. The OOP languages that support real value types essentially have a secondary type system. And as you learn OOP more and more, you realize the key to using OOP properly is to not use it; a point nicely illustrated by Remy making fun of a n00b who actually thought abstract classes were a good idea.

  • I have no words for this! (unregistered)

    pass

  • TheCPUWizard (unregistered)

    Liskov dictates that you should write a robust series of tests for the base class and then pass it each one of the existant derived classes and verify that there is not a violational change..

  • Jake (unregistered)

    I seriously disagree with this being a WTF.

    What is currently a dummy layer can later be modified to suit the specific implementation, without needing to modify the underlying framework (i.e. without modifying core python code). It's basic future-proofing.

    Sure, given in this precise context it seems completely pointless, but if there is (or was) a later plan to modify functionality across all test cases with minimal changes to the (potentially hundreds of) child classes, this is a very reasonable approach.

  • (nodebb)

    In China Mieville's "Perdido Street Station", there is a race of bird people for whom "being too abstract" is a crime, punishable by having your wings torn off and being thrown out of the tribe. Maybe they have the right idea.

  • (nodebb)

    Well, that's one way to be sure that your tests pass...

Leave a comment on “Abstract Test Case”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article