Daimona Eaytoy 904d9cddbb Represent Consequences with command objects ... The consequence-taking logic is moved away from AbuseFilterRunner, to dedicated classes. There's now one class per consequence, encapsulating everything it needs to take the consequence. Several interfaces allow customizing different types of consequences. Every "special check" in AbuseFilter was generalized to use these interfaces, rather than knowing how to handle each consequence. Adding more consequences from other extensions will also be easier, and it should happen via a hook (not a global), returning a class that implements Consequence. The BCConsequence class was temporarily added for legacy custom consequences. A ConsequenceFactory class is added to instantiate consequences; this would possibly benefit from using ObjectFactory, but it doesn't because it would also reduce readability (although we might do that in the future). These classes are still not covered by unit tests, and this is left to do for later. The new unit tests should mostly replace AbuseFilterConsequencesTest. @covers tag were added to keep the status quo (i.e. code that was considered covered while in AbuseFilterRunner will still be considered covered), although we'll have to adjust them. Change-Id: Ia1a9a8bbf55ddd875dfd5bbc55fcd612cff568ef		2020-11-25 17:35:36 +00:00
..
parserTests	Use triple equals in abuse filter parser tests	2020-10-06 12:29:47 -04:00
parserTestsEquivset	Move parser tests to /unit	2019-08-28 16:36:37 +00:00
phpunit	Represent Consequences with command objects	2020-11-25 17:35:36 +00:00
selenium	Simplify ViewEdit, last round	2020-10-26 13:07:29 +00:00