For processors, it should be particularly easy to write proper unit tests. Ideally, before we move the code back to the proper Search API project, all processors should have (passing) unit tests for them.
Done
AddURL.php (#2230873: Test the AddURL processor)
-- ./tests/src/Plugin/Processor/AddUrlTest.php
ContentAccess.php #2252671: Merge CommentAccess and NodeAccess into ContentAccess, provide tests)
-- ./src/Tests//Processor/ContentAccessTest.php
HTMLFilter.php
-- ./tests/src/Plugin/Processor/HtmlFilterTest.php
Ignorecase.php
-- ./tests/src/Plugin/Processor/IgnorecaseTest.php
Language.php
-- ./tests/src/Plugin/Processor/LanguageTest.php
NodeStatus.php (#2258951: NodeStatus Processor)
-- ./tests/src/Plugin/Processor/NodeStatusTest.php
RoleFilter.php (#2255491: RoleFilter processor test coverage)
-- ./tests/src/Plugin/Processor/RoleFilterTest.php
Stopwords.php (#2281233: Fix the Stopwords.php processor)
-- ./tests/src/Plugin/Processor/StopwordsTest.php
Tokenizer.php
-- ./tests/src/Plugin/Processor/Tokenizer.php
Transliteration.php
-- ./src/Tests/TransliterationProcessorTestCase.php
Highlight.php (#2256841: Highlight processor)
-- ./tests/src/Plugin/Processor/HighlightTest.php
RenderedItem.php (#2247923: Test the RenderedItem processor)
-- ./src/Tests/Processor/RenderedItemProcessorTest.php
AddAggregation.php (#2256943: Port "Aggregated fields" processor)
-- Needs tests
FieldsProcessorPluginBase.php (#2286813: Test FieldsProcessorPluginBase)
-- Needs tests
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | processor_test_base-4.patch | 2.44 KB | blueminds |
Comments
Comment #1
drunken monkeyI just went through all the processors for #2230931: Supporting multiple item types per index, and most of them haven't really been ported at all, with a weird mix of D7 and D8 code. So I guess most of the issues should really be "Properly port, test and write unit tests for X processor". Only
Ignorecase(Ha! Also, should beIgnoreCase.) andRenderedItemat least look like they could work.Comment #2
alarcombe commentedA roundup of where we stand wrt processor tests. These are the processors we have, along with tests (if any)
AddAggregation.php
AddURL.php
-- no test
CommentAccess.php
-- no test
HTMLFilter.php
-- ./tests/src/Plugin/Processor/SearchApiHtmlFilterTest.php
Highlight.php
-- ./tests/src/Plugin/Processor/SearchApiHighlightTest.php
Ignorecase.php
-- ./tests/src/Plugin/Processor/SearchApiIgnorecaseTest.php
Language.php
-- no test
NodeAccess.php
-- no test
NodeStatus.php
-- ./src/Tests/SearchApiNodeStatusProcessorTestCase.php
RenderedItem.php
-- no test
RoleFilter.php
-- no test
Stopwords.php
-- ./tests/src/Plugin/Processor/SearchApiStopwordsTest.php
Tokenizer.php
- no test
Transliteration.php
-- ./src/Tests/SearchApiTransliterationProcessorTestCase.php
NB the tests currently are in one of 2 directories, ./src/Tests (and extended from DrupalUnitTestBase, executable from drush/ui), or tests/src/Plugin/Processor (and extended from UnitTestCase, executabel from run-tests.sh - eg php core/scripts/run-tests.sh --class "Drupal\search_api\Tests\Plugin\Processor\SearchApiHtmlFilterTest").
As it stands, all tests pass, so we have three tasks here:
1 - decide upon whether to extend from DrupalUnitTestBase or UnitTestCase (I prefer UnitTestCase) and align the existing tests.
2 - complete tests for plugins which don't currently have them
3 - identify and address drunken_monkey's concerns
Finally, I think Ignorecase test is correctly named as the plugin is called Ignorecase :)
Comment #3
drunken monkeyI meant that both should be changed, in my opinion: ID
ignore_case, classIgnoreCase, testIgnoreCaseTest.Also, if someone wants to work on this, I'd be happy to provide a more detailed explanation of what still needs to be changed for any processor they want to work on. But I thought, maybe this will happen in the sprint next week, when it will be also easier for me to explain.
Comment #4
blueminds commentedAttaching a processor test base class that can be used in the individual processor tests.
Comment #5
blueminds commentedComment #6
blueminds commentedComment #7
blueminds commentedComment #8
blueminds commentedComment #9
blueminds commentedComment #10
blueminds commentedComment #12
nick_vhI reworked tests for :
SearchApiTransliterationTest.php
SearchAPIIgnoreCaseTest.php
The tests now take an item to the processFields method that is more likely to be similar to a Drupal 8 field. Also fieldsProcessorBasePlugin.php was reworked a bit but that did not change the tests too much.
Diff can be seen here:
https://github.com/nickveenhof/search-api-sandbox/commit/58e407263b4b86f...
https://github.com/nickveenhof/search-api-sandbox/commit/3c71d02c6b0855d...
and I've worked on the tests for the HTML filter. Reporting progress in the other thread about that filter.
Comment #13
nick_vhComment #14
nick_vhComment #15
nick_vhComment #16
nick_vhChanged the summary to reflect on the work that has been done in the Search API Sprint @ intracto during the 13th - 15th of June 2014, Belgium.
Thanks to everyone involved!
This means: drunken monkey, borisson_, ekes, Pieter Frenssen, Frederico Taramaschi, Sascha Grossenbacher, Mattias Michaux, LukyLuke_ch, Jasper Lammens, Bram Goffings and Andrei Mateescu
Comment #17
pfrenssenComment #18
drunken monkeyThanks a lot for bringing this up-to-date!
And yes, thanks to everyone who helped this weekend!
Comment #19
drunken monkeyComment #20
drunken monkeyComment #21
drunken monkeyOnly the field processor plugin base class now …
Comment #22
drunken monkeyUnbelievable, but it really seems we're done here!
Later, we can examine where we can improve coverage, but at the moment I think this is certainly good enough to proceed.
Comment #23
pfrenssenGreat news!! A very nice milestone to reach, congratulations!