如何使用自己的方法从外部库扩充类?

发布于 2024-12-03 14:36:34 字数 802 浏览 6 评论 0原文

我有一些特殊情况需要在 django 中进行测试。我正在尝试通过编写自己的测试用例来扩展现有的 django 测试。这是我目前正在做的事情。

from django.tests import TestCase

# define my own method as a function
def assertOptionsEqual(self, first, second):
    # logic here
    pass

# Attach the method to the TestCase class. This feels inelegant!
TestCase.assertOptionsEqual = assertOptionsEqual

# tests go here
class KnownGoodInputs(TestCase):
    def test_good_options(self):
        self.assertOptionsEqual(...)

虽然这可行,但将方法定义为以 self 作为第一个参数的函数,然后将其附加到 TestCase 感觉不太优雅。有没有更好的方法用我自己的方法增强 TestCase 类?我可以这样做......

class MyTestCase(TestCase):
    def assertOptionsEqual(self, first, second):
        ...

并使用 MyTestCase 进行所有测试,但想知道是否有更好的替代方案。谢谢!

I have some special cases that I need to test for in django. I am trying to extend the the existing django tests by writing my own test cases. Here is how I am currently doing it.

from django.tests import TestCase

# define my own method as a function
def assertOptionsEqual(self, first, second):
    # logic here
    pass

# Attach the method to the TestCase class. This feels inelegant!
TestCase.assertOptionsEqual = assertOptionsEqual

# tests go here
class KnownGoodInputs(TestCase):
    def test_good_options(self):
        self.assertOptionsEqual(...)

While this works, defining a method as a function with self as the first parameter and then attaching it to TestCase feels inelegant. Is there a better way of augmenting the TestCase class with my own methods? I can do this ...

class MyTestCase(TestCase):
    def assertOptionsEqual(self, first, second):
        ...

and use MyTestCase for all tests, but was wondering if there was a better alternative. Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

梦途 2024-12-10 14:36:34

我认为您已经涵盖了这两种选择。您可以子类化或猴子补丁。通常,monkeypatching,实际上在运行时更改第 3 方类是不受欢迎的,但根据您需要进行的更改,它可能是解决错误或确保每次使用该类时都有您的新方法的唯一方法。

由于使用您的方法的唯一测试将是您的测试,因此猴子补丁是不必要的,并且子类化TestCase是相当合理的。通常,当您需要增强现有类的方法时,您会使用猴子补丁。例如,如果您希望在现有测试用例中调用 TestCase.assertEqual 来增强逻辑以与 Option 对象进行比较,您可以对 TestCase.assertEqual< /code> 通过执行以下操作来包含您的自定义逻辑及其正常逻辑:

originalAssertEqual = TestCase.assertEqual
def newAssertEqual(self, first, second):
    result = originalAssertEqual(first, second)
    if isinstance(first, Option) and isinstance(second, Option):
        # do your custom comparison
    return result
TestCase.assertEqual = newAssertEqual 

但是,似乎至少在这个示例中,子类和猴子补丁都是不必要的。

假设问题是即使 Option 实例相等,调用 self.assertEqual(firstOptions, secondaryOptions) 也会失败,您不需要编写新的 assertOptionsEqual方法。您可能只需要 Option 对象来正确定义 __eq__

因此,假设您已经有了:

class KnownGoodInputs(TestCase):
    def test_good_options(self):
        first, second = systemUnderTestGetOptions(...)
        self.assertOptionsEqual(first, second)

上面的 firstsecond 的类是什么?

对于所有 Python 内置类型,assertEqual 应该可以工作。对于自定义 Option 类,只需执行以下操作:

class Option(object):
def init(自身):
use_foo = 假
use_bar = True

def __eq__(self, other):
    if (self.use_foo == other.use_foo and
        self.use_bar == other.use_bar):
        return True
    return False

然后假设 firstsecondOption 的实例,您可以将测试编写为:

class KnownGoodInputs(TestCase):
    def test_good_options(self):
        first, second = systemUnderTestGetOptions(...)
        self.assertEqual(first, second)

I think you've covered both options. You can either subclass or monkeypatch. Typically, monkeypatching, actually changing the 3rd party class at runtime is frowned upon but depending on what change you need to make it may be the only way to work around a bug or make sure that every time that class is used it has your new method.

Since the only tests that use your method will be your tests monkeypatching is unnecessary and it's quite reasonable to subclass TestCase. Typically you'd use monkeypatching when you needed to augment a method of a existing class. For example, if you wanted calls to TestCase.assertEqual in your existing test cases to be augmented with logic to compare to Option objects you could monkeypatch TestCase.assertEqual to include your custom logic plus its normal logic by doing something like:

originalAssertEqual = TestCase.assertEqual
def newAssertEqual(self, first, second):
    result = originalAssertEqual(first, second)
    if isinstance(first, Option) and isinstance(second, Option):
        # do your custom comparison
    return result
TestCase.assertEqual = newAssertEqual 

However, it seems that at least in this example that both subclasses and monkeypatches are unnecessary.

Assuming that the issue is that calling self.assertEqual(firstOptions, secondOptions) fails even though the Option instances are equal you don't need to write a new assertOptionsEqual method. You probably just need your Option objects to define __eq__ properly.

So assuming that you've got:

class KnownGoodInputs(TestCase):
    def test_good_options(self):
        first, second = systemUnderTestGetOptions(...)
        self.assertOptionsEqual(first, second)

What are the classes of first and second above?

For all Python builtin types assertEqual should work. For a custom Option class just do something like this:

class Option(object):
def init(self):
use_foo = False
use_bar = True

def __eq__(self, other):
    if (self.use_foo == other.use_foo and
        self.use_bar == other.use_bar):
        return True
    return False

Then assuming that first and second are instances of Option you can write your test just as:

class KnownGoodInputs(TestCase):
    def test_good_options(self):
        first, second = systemUnderTestGetOptions(...)
        self.assertEqual(first, second)
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文