Replace Travis CI with GitHub Actions

.github/workflows/test.yml

@@ -0,0 +1,47 @@
+name: Test
+
+on: [push, pull_request, workflow_dispatch]
+
+env:
+  FORCE_COLOR: 1
+
+jobs:
+  build:
+    runs-on: ${{ matrix.os }}
+    strategy:
+      fail-fast: false
+      matrix:
+        python-version: ["3.5", "3.6", "3.7.7", "3.8"]
+        os: [ubuntu-latest, macos-latest, windows-latest]
+
+    steps:
+      - uses: actions/checkout@v2
+
+      - name: Set up Python ${{ matrix.python-version }}
+        uses: actions/setup-python@v2
+        with:
+          python-version: ${{ matrix.python-version }}
+
+      - name: Get pip cache dir
+        id: pip-cache
+        run: |
+          echo "::set-output name=dir::$(pip cache dir)"
+
+      - name: Cache
+        uses: actions/cache@v2
+        with:
+          path: ${{ steps.pip-cache.outputs.dir }}
+          key:
+            ${{ matrix.os }}-${{ matrix.python-version }}-v1-${{ hashFiles('**/setup.py') }}
+          restore-keys: |
+            ${{ matrix.os }}-${{ matrix.python-version }}-v1-
+
+      - name: Install dependencies
+        run: |
+          python -m pip install -U pip
+          python -m pip install -U wheel
+          python -m pip install -U tox
+
+      - name: Test
+        run: |
+          tox -e py

README.html

@@ -357,7 +357,7 @@ <h1 class="title">Nose2pytest version 1.0.4 documentation</h1>
 </div>
 <div class="section" id="overview">
 <h1><a class="toc-backref" href="#id1">Overview</a></h1>
-<p>This package provides a Python script and py.test plugin to help convert Nose-based tests into py.test-based
+<p>This package provides a Python script and pytest plugin to help convert Nose-based tests into pytest-based
 tests. Specifically, the script transforms <tt class="docutils literal">nose.tools.assert_*</tt> function calls into raw assert statements,
 while preserving format of original arguments as much as possible. For example, the script</p>
 <pre class="literal-block">
@@ -371,7 +371,7 @@ <h1><a class="toc-backref" href="#id1">Overview</a></h1>
 </pre>
 <p>A small subset of <tt class="docutils literal">nose.tools.assert_*</tt> function calls are not
 transformed because there is no raw assert statement equivalent, or the equivalent would be hard to
-maintain. They are provided as functions in the pytest namespace via py.test's plugin system.</p>
+maintain. They are provided as functions in the pytest namespace via pytest's plugin system.</p>
 </div>
 <div class="section" id="installation">
 <h1><a class="toc-backref" href="#id2">Installation</a></h1>
@@ -399,29 +399,29 @@ <h1><a class="toc-backref" href="#id4">Motivation</a></h1>
 are not as convenient to use as raw assertions, since you have to decide before hand what type of assertion you
 are going to write: an identity comparison to None, a truth check, a falseness check, an identity comparison to another
 object, etc. Just being able to write a raw assertion, and still get good diagnostics on failure as done by
-py.test, is really nice. This is a main reason for using py.test for me. Another reason is the design of fixtures
-in py.test.</p>
-<p>Switching an existing test suite from Nose to py.test is feasible even without nose2pytest, as it requires
+pytest, is really nice. This is a main reason for using pytest for me. Another reason is the design of fixtures
+in pytest.</p>
+<p>Switching an existing test suite from Nose to pytest is feasible even without nose2pytest, as it requires
 relatively little work: <em>relatively</em> as in, you will probably only need a few modifications, all achievable
 manually, to get the same test coverage and results. A few gotchas:</p>
 <ul class="simple">
 <li>test classes that have <tt class="docutils literal">__init__</tt> will be ignored, those will have to be moved (usually, into class's
 <tt class="docutils literal">setup_class()</tt>)</li>
-<li>the <tt class="docutils literal">setup.cfg</tt> may have to be edited since test discovery rules are slightly more strict with py.test</li>
+<li>the <tt class="docutils literal">setup.cfg</tt> may have to be edited since test discovery rules are slightly more strict with pytest</li>
 <li>the order of tests may be different, but in general that should not matter</li>
 <li>all test modules are imported up-front, so some test modules may need adjustment such as moving some
 code from the top of the test module into its <tt class="docutils literal">setup_module()</tt></li>
 </ul>
 <p>Once the above has been done to an existing code base, you don't really have to do anything else. However, your test
 suite now has an additional third-party test dependency (Nose), just because of those <tt class="docutils literal">assert_*</tt> functions used all
 over the place. Moreover, there is no longer one obvious way to do things in your test suite: existing test code
-uses <tt class="docutils literal">nose.tools.assert_*</tt> functions, yet with py.test you can use raw assertions. If you add tests, which of
+uses <tt class="docutils literal">nose.tools.assert_*</tt> functions, yet with pytest you can use raw assertions. If you add tests, which of
 these two approaches should a developer use? If you modify existing tests, should new assertions use raw assert?
 Should the remaining test method, test class, or test module be updated? A test module can contain hundreds of
 calls to <tt class="docutils literal">nose.tools.assert_*</tt> functions, is a developer to manually go through each one to convert it? Painful and
 error prone, in general not feasible to do manually.</p>
-<p>This is why I developed nose2pytest: I wanted to migrate my pypubsub project's test suite from Nose to py.test,
-but also have only py.test as a dependency, and have one obvious way to write assertions in the test suite.</p>
+<p>This is why I developed nose2pytest: I wanted to migrate my pypubsub project's test suite from Nose to pytest,
+but also have only pytest as a dependency, and have one obvious way to write assertions in the test suite.</p>
 </div>
 <div class="section" id="requirements">
 <h1><a class="toc-backref" href="#id5">Requirements</a></h1>
@@ -433,7 +433,7 @@ <h1><a class="toc-backref" href="#id5">Requirements</a></h1>
 Nose 1.3.7 on Windows 7 Pro 64. If you have successfully used nose2pytest with other combinations, please
 kindly let me know (via github).</p>
 <p>The pytest package namespace will be extended with <tt class="docutils literal">assert_</tt> functions that are not converted by the script
-only if, err, you have py.test installed!</p>
+only if, err, you have pytest installed!</p>
 </div>
 <div class="section" id="status">
 <h1><a class="toc-backref" href="#id6">Status</a></h1>
@@ -583,7 +583,7 @@ <h1><a class="toc-backref" href="#id6">Status</a></h1>
 </ul>
 <p>The nose2pytest distribution contains a module, <tt class="docutils literal">assert_tools.py</tt> which defines these utility functions to
 contain the equivalent raw assert statement. Copy the module into your test folder or into the pytest package
-and change your test code's <tt class="docutils literal">from nose.tools import ...</tt> statements accordingly. Py.test introspection will
+and change your test code's <tt class="docutils literal">from nose.tools import ...</tt> statements accordingly. pytest introspection will
 provide error information on assertion failure.</p>
 </li>
 <li><p class="first">Some Nose functions don't have a one-line assert statement equivalent, they have to remain utility functions:</p>

README.rst

@@ -1,7 +1,7 @@
 .. image:: https://badge.fury.io/py/nose2pytest.svg
     :target: https://badge.fury.io/py/nose2pytest
-.. image:: https://img.shields.io/travis/pytest-dev/nose2pytest.svg
-    :target: https://img.shields.io/travis/pytest-dev/nose2pytest
+.. image:: https://github.com/pytest-dev/nose2pytest/workflows/Test/badge.svg
+    :target: https://github.com/pytest-dev/nose2pytest/actions
 
 
 .. contents::
@@ -10,7 +10,7 @@
 Overview
 ------------
 
-This package provides a Python script and py.test plugin to help convert Nose-based tests into py.test-based 
+This package provides a Python script and pytest plugin to help convert Nose-based tests into pytest-based
 tests. Specifically, the script transforms ``nose.tools.assert_*`` function calls into raw assert statements, 
 while preserving format of original arguments as much as possible. For example, the script:
 
@@ -28,7 +28,7 @@ gets converted to:
 
 A small subset of ``nose.tools.assert_*`` function calls are not 
 transformed because there is no raw assert statement equivalent, or the equivalent would be hard to 
-maintain. They are provided as functions in the pytest namespace via py.test's plugin system.
+maintain. They are provided as functions in the pytest namespace via pytest's plugin system.
 
 
 Installation
@@ -62,31 +62,31 @@ ought to use the ``assert_*()`` functions from ``nose.tools``. Although they pro
 are not as convenient to use as raw assertions, since you have to decide before hand what type of assertion you 
 are going to write: an identity comparison to None, a truth check, a falseness check, an identity comparison to another 
 object, etc. Just being able to write a raw assertion, and still get good diagnostics on failure as done by 
-py.test, is really nice. This is a main reason for using py.test for me. Another reason is the design of fixtures
-in py.test.
+pytest, is really nice. This is a main reason for using pytest for me. Another reason is the design of fixtures
+in pytest.
 
-Switching an existing test suite from Nose to py.test is feasible even without nose2pytest, as it requires 
+Switching an existing test suite from Nose to pytest is feasible even without nose2pytest, as it requires
 relatively little work: *relatively* as in, you will probably only need a few modifications, all achievable 
 manually, to get the same test coverage and results. A few gotchas: 
 
 - test classes that have ``__init__`` will be ignored, those will have to be moved (usually, into class's 
   ``setup_class()``)
-- the ``setup.cfg`` may have to be edited since test discovery rules are slightly more strict with py.test
+- the ``setup.cfg`` may have to be edited since test discovery rules are slightly more strict with pytest
 - the order of tests may be different, but in general that should not matter
 - all test modules are imported up-front, so some test modules may need adjustment such as moving some 
   code from the top of the test module into its ``setup_module()`` 
 
 Once the above has been done to an existing code base, you don't really have to do anything else. However, your test 
 suite now has an additional third-party test dependency (Nose), just because of those ``assert_*`` functions used all 
 over the place. Moreover, there is no longer one obvious way to do things in your test suite: existing test code 
-uses ``nose.tools.assert_*`` functions, yet with py.test you can use raw assertions. If you add tests, which of 
+uses ``nose.tools.assert_*`` functions, yet with pytest you can use raw assertions. If you add tests, which of
 these two approaches should a developer use? If you modify existing tests, should new assertions use raw assert? 
 Should the remaining test method, test class, or test module be updated? A test module can contain hundreds of 
 calls to ``nose.tools.assert_*`` functions, is a developer to manually go through each one to convert it? Painful and 
 error prone, in general not feasible to do manually. 
 
-This is why I developed nose2pytest: I wanted to migrate my pypubsub project's test suite from Nose to py.test,
-but also have only py.test as a dependency, and have one obvious way to write assertions in the test suite. 
+This is why I developed nose2pytest: I wanted to migrate my pypubsub project's test suite from Nose to pytest,
+but also have only pytest as a dependency, and have one obvious way to write assertions in the test suite.
 
 
 Requirements
@@ -102,7 +102,7 @@ Nose 1.3.7 on Windows 7 Pro 64. If you have successfully used nose2pytest with o
 kindly let me know (via github). 
 
 The pytest package namespace will be extended with ``assert_`` functions that are not converted by the script
-only if, err, you have py.test installed!
+only if, err, you have pytest installed!
 
 
 Status
@@ -187,7 +187,7 @@ Not every ``assert_*`` function from ``nose.tools`` is converted by nose2pytest:
 
    The nose2pytest distribution contains a module, ``assert_tools.py`` which defines these utility functions to 
    contain the equivalent raw assert statement. Copy the module into your test folder or into the pytest package 
-   and change your test code's ``from nose.tools import ...`` statements accordingly. Py.test introspection will 
+   and change your test code's ``from nose.tools import ...`` statements accordingly. pytest introspection will
    provide error information on assertion failure.
 
 3. Some Nose functions don't have a one-line assert statement equivalent, they have to remain utility functions:

nose2pytest/assert_tools.py

@@ -5,7 +5,7 @@
 
 This module's assert_ functions provide drop-in replacements for nose.tools.assert_ functions (many of which are
 pep-8-ized extractions from Python's unittest.case.TestCase methods). As such, it can be imported in a test
-suite run by py.test, to replace the nose imports with functions that rely on py.test's assertion
+suite run by pytest, to replace the nose imports with functions that rely on pytest's assertion
 introspection for error reporting.  When combined with running nose2pytest.py on your test suite, this
 module may be sufficient to decrease your test suite's third-party dependencies by 1.
 """
@@ -93,7 +93,7 @@ def do_nothing(self):
 del _t
 
 
-# py.test integration: add all assert_ function to the pytest package namespace
+# pytest integration: add all assert_ function to the pytest package namespace
 
 # Use similar trick as Nose to bring in bound methods from unittest.TestCase as free functions:
 

setup.py

@@ -19,6 +19,7 @@
         description='Convert nose.tools.assert_ calls found in your Nose test modules into raw asserts for pytest',
         keywords='nose to pytest conversion',
 
+        python_requires='>=3.5',
         classifiers=[
             # How mature is this project? Common values are
             #   3 - Alpha
@@ -34,8 +35,11 @@
             'License :: OSI Approved :: BSD License',
 
             # Specify the Python versions you support here.
-            'Programming Language :: Python :: 3.4',
+            'Programming Language :: Python :: 3',
+            'Programming Language :: Python :: 3 :: Only',
             'Programming Language :: Python :: 3.5',
             'Programming Language :: Python :: 3.6',
+            'Programming Language :: Python :: 3.7',
+            'Programming Language :: Python :: 3.8',
         ],
 )

tox.ini

@@ -1,9 +1,9 @@
 [tox]
-envlist = py34, py35, py36, py37, py38
+envlist = py35, py36, py37, py38
 
 [testenv]
 deps =
     pytest
     nose
 
-commands = py.test
+commands = pytest