Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test cases for patchy #2

Open
levic opened this issue Nov 23, 2017 · 3 comments
Open

Test cases for patchy #2

levic opened this issue Nov 23, 2017 · 3 comments

Comments

@levic
Copy link

levic commented Nov 23, 2017

It would be nice to have test cases for the various patching edge cases.

  • patching and original class reference stays the same
  • patching and calling the original function
  • patching and bypassing the original function but still calling super()
  • patching where the patched function was obtained via a descriptor
  • patching a class that with multiple inheritance
  • patching a class that with diamond inheritance
  • patching where an instance of that class has already been created
  • patching where an instance of that class has already been created and overrides the patched function on the instance itself (if they took a reference to the original function to wrap it then this will fail -- can mark as skipped to indicate that this is a known failure case)
  • patching where an instance of that class has already been created and overrides the patched function on the instance itself and calls super() [patched function will not be called -- working as intended]
  • patching a class that has a metaclass -- metaclass should not be invoked
  • patching a class where an ancestor has a metaclass (eg django models) -- metaclass should not be invoked
@levic
Copy link
Author

levic commented Nov 23, 2017

  • patching where __subclasshook__, __subclasscheck__ or __instancecheck__ are overridden (should work for current implementation; alternate implementations may fail)
  • patching where __getattribute__ are overridden
  • patching where __getattr__, __setattr__ are overridden
  • patching where __dir__ defined
  • patching a descriptor
  • patching where __slots__ defined
  • patching where __init_subclass__ defined (presumably __init_subclass__ shouldn't be invoked)
  • patching a function that exists on an ancestor class but not on this class
  • patching a @classmethod
  • patching a @staticmethod
  • patching a @classmethod that exists on an ancestor class but not on the target class
  • patching a @staticmethod that exists on an ancestor class but not on the target class

@ashleywaite
Copy link
Owner

That's a great list of things to test for, and raises a couple of the caveats that should be documented as well.
ie, patching in a function that calls super, you need to tell super the reference point super(self.__class__, self) instead of a bare super() to ensure it uses the mro of the class you patched into instead of the one the function was defined in.

@levic
Copy link
Author

levic commented Nov 23, 2017

  • patching where the class is subclassed (specifically, subclass instances calling super() should go to the patched function)

AlexanderTar referenced this issue in OakNorthAI/django-more Sep 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants