Skip to content

Port test/test_functional_tensor.py to pytest #3956

@NicolasHug

Description

@NicolasHug

Currently, most tests in test/test_functional_tensor.py rely on unittest.TestCase. Now that we support pytest, we want to remove the use of the unittest module.

Instructions

There are many tests in this file, so I bundled them in multiple related groups below. If you're interested in working on this issue, please comment below with "I'm working on <group X>, <group Y>, etc..." so that others don't pick the same tests as you do. Feel free to pick as many groups as you wish, but please don't submit more than 2 groups per PR in order to keep the reviews manageable. Before picking a group, make sure it wasn't picked by another contributor first. Thanks!!

How to port a test to pytest

Porting a test from unittest to pytest is usually fairly straightforward. For a typical example, see https://github.com/pytorch/vision/pull/3907/files:

  • take the test method out of the Tester(unittest.TestCase) class and just declare it as a function
  • Replace @unittest.skipIf with pytest.mark.skipif(cond, reason=...)
  • remove any use of self.assertXYZ.
    • Typically assertEqual(a, b) can be replaced by assert a == b when a and b are pure python objects (scalars, tuples, lists), and otherwise we can rely on assert_equal which is already used in the file.
    • self.assertRaises should be replaced with the pytest.raises(Exp, match=...): context manager, as done in https://github.com/pytorch/vision/pull/3907/files. Same for warnings with pytest.warns
    • self.assertTrue should be replaced with a plain assert
  • When a function uses for loops to tests multiple parameter values, one should usepytest.mark.parametrize instead, as done e.g. in https://github.com/pytorch/vision/pull/3907/files.
  • It may make sense to keep related tests within a single class. For example here, the tests in group A could be grouped into a TestToPILImage class, the tests in group N could be in TestPad, etc. Not all groups need a dedicated class though, it's on a case-by-case basis.
  • Important: a lot of these tests rely on self.device because they need to be run on both CPU and GPU. For these, use the cpu_and_gpu() from common_utils instead, e.g.:

@pytest.mark.parametrize('device', cpu_and_gpu())
def test_resize_asserts(device):

and you can just replace self.device by device in the test

CC @saswatpp as promised!


(EDIT: oops, I initially named both groups below Group B. Renamed into B1 and B2)

cc @pmeier @vfdev-5

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions