spaCy/spacy/tests
Paul O'Leary McCann 6920fb7baf
Move Entity Linker v1 to spacy-legacy (#12006)
* Move Entity Linker v1 component to spacy-legacy

This is a follow up to #11889 that moves the component instead of
removing it.

In general, we never import from spacy-legacy in spaCy proper. However,
to use this component, that kind of import will be necessary. I was able
to test this without issues, but is this current import strategy
acceptable? Or should we put the component in a registry?

* Use spacy-legacy pr for CI

This will need to be reverted before merging.

* Add temporary step to log installed spacy-legacy version

* Modify requirements.txt to trigger tests

* Add comment to Python to trigger tests

* TODO REVERT This is a commit with logic changes to trigger tests

* Remove pipe from YAML

Works locally, but possibly this is causing a quoting error or
something.

* Revert "TODO REVERT This is a commit with logic changes to trigger tests"

This reverts commit 689fae71f3.

* Revert "Add comment to Python to trigger tests"

This reverts commit 11840fc598.

* Add more logging

* Try installing directly in workflow

* Try explicitly uninstalling spacy-legacy first

* Cat requirements.txt to confirm contents

In the branch, the thinc version spec is `thinc>=8.1.0,<8.2.0`. But in
the logs, it's clear that a development release of 9.0 is being
installed. It's not clear why that would happen.

* Log requirements at start of build

* TODO REVERT Change thinc spec

Want to see what happens to the installed thinc spec with this change.

* Update thinc requirements

This makes it the same as it was before the merge, >=8.1.0,<8.2.0.

* Use same thinc version as v4 branch

* TODO REVERT Mark dependency check as xfail

spacy-legacy is specified as a git checkout in requirements.txt while
this PR is in progress, which makes the consistency check here fail.

* Remove debugging output / install step

* Revert "Remove debugging output / install step"

This reverts commit 923ea7448b.

* Clean up debugging output

The manual install step with the URL fragment seems to have caused
issues on Windows due to the = in the URL being misinterpreted. On the
other hand, removing it seems to mean the git version of spacy-legacy
isn't actually installed.

This PR removes the URL fragment but keeps the direct command-line
install. Additionally, since it looks like this job is configured to use
the default shell (and not bash), it removes a comment that upsets the
Windows cmd shell.

* Revert "TODO REVERT Mark dependency check as xfail"

This reverts commit d4863ec156.

* Fix requirements.txt, increasing spacy-legacy version

* Raise spacy legacy version in setup.cfg

* Remove azure build workarounds

* make spacy-legacy version explicit in error message

* Remove debugging line

* Suggestions from code review
2023-02-01 09:47:56 +01:00
..
doc Rename language codes (Icelandic, multi-language) (#12149) 2023-01-31 17:30:43 +01:00
lang Rename language codes (Icelandic, multi-language) (#12149) 2023-01-31 17:30:43 +01:00
matcher Merge branch 'copy_master' into copy_v4 2023-01-11 18:40:55 +01:00
morphology Tidy up and auto-format 2020-08-09 22:36:23 +02:00
package Merge branch 'develop' into merge-develop-into-v4 2022-09-07 11:35:47 +02:00
parser Merge the parser refactor into v4 (#10940) 2023-01-18 11:27:45 +01:00
pipeline Move Entity Linker v1 to spacy-legacy (#12006) 2023-02-01 09:47:56 +01:00
serialize Add the configuration schema for distillation (#12201) 2023-01-31 13:06:02 +01:00
tokenizer Rename language codes (Icelandic, multi-language) (#12149) 2023-01-31 17:30:43 +01:00
training Merge remote-tracking branch 'upstream/master' into update-v4-from-master-1 2023-01-27 08:29:09 +01:00
vocab_vectors Merge branch 'copy_master' into copy_v4 2022-12-05 08:56:15 +01:00
__init__.py Revert #4334 2019-09-29 17:32:12 +02:00
conftest.py Rename language codes (Icelandic, multi-language) (#12149) 2023-01-31 17:30:43 +01:00
enable_gpu.py Set up GPU CI testing (#7293) 2021-04-22 14:58:29 +02:00
README.md Rename language codes (Icelandic, multi-language) (#12149) 2023-01-31 17:30:43 +01:00
test_architectures.py Tidy up code 2021-06-28 12:08:15 +02:00
test_cli_app.py trainable_lemmatizer in debug data (#11419) 2023-01-26 17:36:50 +01:00
test_cli.py trainable_lemmatizer in debug data (#11419) 2023-01-26 17:36:50 +01:00
test_displacy.py Don't throw an error if using displacy on an unset span key (#11845) 2022-11-28 10:01:09 +01:00
test_errors.py use metaclass to decorate errors (#9593) 2021-11-03 15:29:32 +01:00
test_language.py Rename language codes (Icelandic, multi-language) (#12149) 2023-01-31 17:30:43 +01:00
test_misc.py Merge the parser refactor into v4 (#10940) 2023-01-18 11:27:45 +01:00
test_models.py Rename test helper method with non-test_ name (#11701) 2022-10-25 14:53:18 +02:00
test_pickles.py Include noun chunks method when pickling Vocab 2021-02-12 13:27:46 +01:00
test_scorer.py Restore v2 token_acc score implementation (#12073) 2023-01-11 08:01:47 +01:00
test_symbols.py Consolidate and freeze symbols (#11352) 2022-09-02 09:08:40 +02:00
test_ty.py Custom component types in spacy.ty (#9469) 2021-10-21 15:31:06 +02:00
util.py account for NER labels with a hyphen in the name (#10960) 2022-06-17 20:02:37 +01:00

spaCy tests

spaCy uses the pytest framework for testing. For more info on this, see the pytest documentation.

Tests for spaCy modules and classes live in their own directories of the same name. For example, tests for the Tokenizer can be found in /tests/tokenizer. All test modules (i.e. directories) also need to be listed in spaCy's setup.py. To be interpreted and run, all test files and test functions need to be prefixed with test_.

⚠️ Important note: As part of our new model training infrastructure, we've moved all model tests to the spacy-models repository. This allows us to test the models separately from the core library functionality.

Table of contents

  1. Running the tests
  2. Dos and don'ts
  3. Parameters
  4. Fixtures
  5. Helpers and utilities
  6. Contributing to the tests

Running the tests

To show print statements, run the tests with py.test -s. To abort after the first failure, run them with py.test -x.

py.test spacy                        # run basic tests
py.test spacy --slow                 # run basic and slow tests

You can also run tests in a specific file or directory, or even only one specific test:

py.test spacy/tests/tokenizer  # run all tests in directory
py.test spacy/tests/tokenizer/test_exceptions.py # run all tests in file
py.test spacy/tests/tokenizer/test_exceptions.py::test_tokenizer_handles_emoji # run specific test

Dos and don'ts

To keep the behavior of the tests consistent and predictable, we try to follow a few basic conventions:

  • Test names should follow a pattern of test_[module]_[tested behaviour]. For example: test_tokenizer_keeps_email.
  • If you're testing for a bug reported in a specific issue, always create a regression test. Regression tests should be named test_issue[ISSUE NUMBER] and live in the regression directory.
  • Only use @pytest.mark.xfail for tests that should pass, but currently fail. To test for desired negative behavior, use assert not in your test.
  • Very extensive tests that take a long time to run should be marked with @pytest.mark.slow. If your slow test is testing important behavior, consider adding an additional simpler version.
  • If tests require loading the models, they should be added to the spacy-models tests.
  • Before requiring the models, always make sure there is no other way to test the particular behavior. In a lot of cases, it's sufficient to simply create a Doc object manually. See the section on helpers and utility functions for more info on this.
  • Avoid unnecessary imports. There should never be a need to explicitly import spaCy at the top of a file, and many components are available as fixtures. You should also avoid wildcard imports (from module import *).
  • If you're importing from spaCy, always use absolute imports. For example: from spacy.language import Language.
  • Try to keep the tests readable and concise. Use clear and descriptive variable names (doc, tokens and text are great), keep it short and only test for one behavior at a time.

Parameters

If the test cases can be extracted from the test, always parametrize them instead of hard-coding them into the test:

@pytest.mark.parametrize('text', ["google.com", "spacy.io"])
def test_tokenizer_keep_urls(tokenizer, text):
    tokens = tokenizer(text)
    assert len(tokens) == 1

This will run the test once for each text value. Even if you're only testing one example, it's usually best to specify it as a parameter. This will later make it easier for others to quickly add additional test cases without having to modify the test.

You can also specify parameters as tuples to test with multiple values per test:

@pytest.mark.parametrize('text,length', [("U.S.", 1), ("us.", 2), ("(U.S.", 2)])

To test for combinations of parameters, you can add several parametrize markers:

@pytest.mark.parametrize('text', ["A test sentence", "Another sentence"])
@pytest.mark.parametrize('punct', ['.', '!', '?'])

This will run the test with all combinations of the two parameters text and punct. Use this feature sparingly, though, as it can easily cause unnecessary or undesired test bloat.

Fixtures

Fixtures to create instances of spaCy objects and other components should only be defined once in the global conftest.py. We avoid having per-directory conftest files, as this can easily lead to confusion.

These are the main fixtures that are currently available:

Fixture Description
tokenizer Basic, language-independent tokenizer. Identical to the mul language class.
en_tokenizer, de_tokenizer, ... Creates an English, German etc. tokenizer.
en_vocab Creates an instance of the English Vocab.

The fixtures can be used in all tests by simply setting them as an argument, like this:

def test_module_do_something(en_tokenizer):
    tokens = en_tokenizer("Some text here")

If all tests in a file require a specific configuration, or use the same complex example, it can be helpful to create a separate fixture. This fixture should be added at the top of each file. Make sure to use descriptive names for these fixtures and don't override any of the global fixtures listed above. From looking at a test, it should immediately be clear which fixtures are used, and where they are coming from.

Helpers and utilities

Our new test setup comes with a few handy utility functions that can be imported from util.py.

Constructing a Doc object manually

Loading the models is expensive and not necessary if you're not actually testing the model performance. If all you need is a Doc object with annotations like heads, POS tags or the dependency parse, you can construct it manually.

def test_doc_token_api_strings(en_vocab):
    words = ["Give", "it", "back", "!", "He", "pleaded", "."]
    pos = ['VERB', 'PRON', 'PART', 'PUNCT', 'PRON', 'VERB', 'PUNCT']
    heads = [0, 0, 0, 0, 5, 5, 5]
    deps = ['ROOT', 'dobj', 'prt', 'punct', 'nsubj', 'ROOT', 'punct']

    doc = Doc(en_vocab, words=words, pos=pos, heads=heads, deps=deps)
    assert doc[0].text == 'Give'
    assert doc[0].lower_ == 'give'
    assert doc[0].pos_ == 'VERB'
    assert doc[0].dep_ == 'ROOT'

Other utilities

Name Description
apply_transition_sequence(parser, doc, sequence) Perform a series of pre-specified transitions, to put the parser in a desired state.
add_vecs_to_vocab(vocab, vectors) Add list of vector tuples ([("text", [1, 2, 3])]) to given vocab. All vectors need to have the same length.
get_cosine(vec1, vec2) Get cosine for two given vectors.
assert_docs_equal(doc1, doc2) Compare two Doc objects and assert that they're equal. Tests for tokens, tags, dependencies and entities.

Contributing to the tests

There's still a long way to go to finally reach 100% test coverage and we'd appreciate your help! 🙌 You can open an issue on our issue tracker and label it tests, or make a pull request to this repository.

📖 For more information on contributing to spaCy in general, check out our contribution guidelines.