mirror of
				https://github.com/explosion/spaCy.git
				synced 2025-10-31 07:57:35 +03:00 
			
		
		
		
	## Description Related issues: #2379 (should be fixed by separating model tests) * **total execution time down from > 300 seconds to under 60 seconds** 🎉 * removed all model-specific tests that could only really be run manually anyway – those will now live in a separate test suite in the [`spacy-models`](https://github.com/explosion/spacy-models) repository and are already integrated into our new model training infrastructure * changed all relative imports to absolute imports to prepare for moving the test suite from `/spacy/tests` to `/tests` (it'll now always test against the installed version) * merged old regression tests into collections, e.g. `test_issue1001-1500.py` (about 90% of the regression tests are very short anyways) * tidied up and rewrote existing tests wherever possible ### Todo - [ ] move tests to `/tests` and adjust CI commands accordingly - [x] move model test suite from internal repo to `spacy-models` - [x] ~~investigate why `pipeline/test_textcat.py` is flakey~~ - [x] review old regression tests (leftover files) and see if they can be merged, simplified or deleted - [ ] update documentation on how to run tests ### Types of change enhancement, tests ## Checklist <!--- Before you submit the PR, go over this checklist and make sure you can tick off all the boxes. [] -> [x] --> - [x] I have submitted the spaCy Contributor Agreement. - [x] I ran the tests, and all new and existing tests passed. - [ ] My changes don't require a change to the documentation, or if they do, I've added all required information.
		
			
				
	
	
		
			52 lines
		
	
	
		
			2.4 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			52 lines
		
	
	
		
			2.4 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| //- 💫 DOCS > USAGE > ADDING LANGUAGES > TESTING
 | ||
| 
 | ||
| p
 | ||
|     |  Before using the new language or submitting a
 | ||
|     |  #[+a(gh("spaCy") + "/pulls") pull request] to spaCy, you should make sure
 | ||
|     |  it works as expected. This is especially important if you've added custom
 | ||
|     |  regular expressions for token matching or punctuation – you don't want to
 | ||
|     |  be causing regressions.
 | ||
| 
 | ||
| +infobox("spaCy's test suite")
 | ||
|     |  spaCy uses the #[+a("https://docs.pytest.org/en/latest/") pytest framework]
 | ||
|     |  for testing. For more details on how the tests are structured and best
 | ||
|     |  practices for writing your own tests, see our
 | ||
|     |  #[+a(gh("spaCy", "spacy/tests")) tests documentation].
 | ||
| 
 | ||
| +h(3, "testing-custom") Writing language-specific tests
 | ||
| 
 | ||
| p
 | ||
|     |  It's recommended to always add at least some tests with examples specific
 | ||
|     |  to the language. Language tests should be located in
 | ||
|     |  #[+src(gh("spaCy", "spacy/tests/lang")) #[code tests/lang]] in a
 | ||
|     |  directory named after the language ID. You'll also need to create a
 | ||
|     |  fixture for your tokenizer in the
 | ||
|     |  #[+src(gh("spaCy", "spacy/tests/conftest.py")) #[code conftest.py]].
 | ||
|     |  Always use the #[+api("util#get_lang_class") #[code get_lang_class()]]
 | ||
|     |  helper function within the fixture, instead of importing the class at the
 | ||
|     |  top of the file. This will load the language data only when it's needed.
 | ||
|     |  (Otherwise, #[em all data] would be loaded every time you run a test.)
 | ||
| 
 | ||
| +code.
 | ||
|     @pytest.fixture
 | ||
|     def en_tokenizer():
 | ||
|         return util.get_lang_class('en').Defaults.create_tokenizer()
 | ||
| 
 | ||
| p
 | ||
|     |  When adding test cases, always
 | ||
|     |  #[+a(gh("spaCy", "spacy/tests#parameters")) #[code parametrize]] them –
 | ||
|     |  this will make it easier for others to add more test cases without having
 | ||
|     |  to modify the test itself. You can also add parameter tuples, for example,
 | ||
|     |  a test sentence and its expected length, or a list of expected tokens.
 | ||
|     |  Here's an example of an English tokenizer test for combinations of
 | ||
|     |  punctuation and abbreviations:
 | ||
| 
 | ||
| +code("Example test").
 | ||
|     @pytest.mark.parametrize('text,length', [
 | ||
|         ("The U.S. Army likes Shock and Awe.", 8),
 | ||
|         ("U.N. regulations are not a part of their concern.", 10),
 | ||
|         ("“Isn't it?”", 6)])
 | ||
|     def test_en_tokenizer_handles_punct_abbrev(en_tokenizer, text, length):
 | ||
|         tokens = en_tokenizer(text)
 | ||
|         assert len(tokens) == length
 |