wikimedia/mediawiki-extensions-Cite
1
0
Fork 0
mirror of https://gerrit.wikimedia.org/r/mediawiki/extensions/Cite synced 2024-11-28 00:40:12 +00:00
Code Issues Packages Projects Releases Wiki Activity
mediawiki-extensions-Cite/tests/parser/citeSmokeTests.txt

147 lines
7 KiB
Plaintext
Raw Normal View History

Update parser tests to v2 (tidy by default) The most common cleanup required by switching to tidy output was adding missing <p>-wrappers to the last item before <references/>. Bug: T246285 Change-Id: I7c8a08c4e6eff7caf4539a26fae475a4133f9a0c
2020-01-28 22:48:13 +00:00
!! version 2
Add parser & unit test cases for different $wgFragmentMode's This is only to document the current status quo and make later patches smaller and easier to review. Bug: T298278 Change-Id: I6c78f4d3ee32de596f2b5ee081d56eaffb1cc7bd
2022-01-03 13:10:47 +00:00
Add smoke tests for previously uncovered combinations I noticed a possible issue related to the $this->refSequence counter in the patch Ida9612d. Some of these counters might get messes up, but there was never a test that checked what will happen to the *next* reference then. I checked the test cases in this patch with a very old version of the codebase. Change-Id: If6e56f727dce5d0e5e38e048e602437597248a42
2019-11-27 15:31:53 +00:00
!! test
Smoke test for duplicated references with the same text
!! wikitext
<ref name="a">text</ref>
<ref name="a">text</ref>
<ref name="b">other</ref>
!! html
<p><sup id="cite_ref-a_1-0" class="reference"><a href="#cite_note-a-1">&#91;1&#93;</a></sup>
<sup id="cite_ref-a_1-1" class="reference"><a href="#cite_note-a-1">&#91;1&#93;</a></sup>
Add a newline in wikitext before autogenerated reflist Previously the reflist was added at the end of the last line of text, which messes up paragraph wrapping (as seen in many test cases), and generated invalid HTML when the last line was a list item (T148701). (second try, previously reverted in 8c933d03c573f7cacf7c385e6fb89d61d6fd7633) Note this affects only pages where the <references /> tag is missing, and the references section is auto-generated at the very end of the page. Bug: T148701 Change-Id: Ib2101346434a4e317b5fc7379215b60c7020cb2b
2020-04-01 22:13:31 +00:00
<sup id="cite_ref-b_2-0" class="reference"><a href="#cite_note-b-2">&#91;2&#93;</a></sup>
Add smoke tests for previously uncovered combinations I noticed a possible issue related to the $this->refSequence counter in the patch Ida9612d. Some of these counters might get messes up, but there was never a test that checked what will happen to the *next* reference then. I checked the test cases in this patch with a very old version of the codebase. Change-Id: If6e56f727dce5d0e5e38e048e602437597248a42
2019-11-27 15:31:53 +00:00
</p>
Add a newline in wikitext before autogenerated reflist Previously the reflist was added at the end of the last line of text, which messes up paragraph wrapping (as seen in many test cases), and generated invalid HTML when the last line was a list item (T148701). (second try, previously reverted in 8c933d03c573f7cacf7c385e6fb89d61d6fd7633) Note this affects only pages where the <references /> tag is missing, and the references section is auto-generated at the very end of the page. Bug: T148701 Change-Id: Ib2101346434a4e317b5fc7379215b60c7020cb2b
2020-04-01 22:13:31 +00:00
<div class="mw-references-wrap"><ol class="references">
Add smoke tests for previously uncovered combinations I noticed a possible issue related to the $this->refSequence counter in the patch Ida9612d. Some of these counters might get messes up, but there was never a test that checked what will happen to the *next* reference then. I checked the test cases in this patch with a very old version of the codebase. Change-Id: If6e56f727dce5d0e5e38e048e602437597248a42
2019-11-27 15:31:53 +00:00
<li id="cite_note-a-1"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-a_1-0">1.0</a></sup> <sup><a href="#cite_ref-a_1-1">1.1</a></sup></span> <span class="reference-text">text</span>
</li>
<li id="cite_note-b-2"><span class="mw-cite-backlink"><a href="#cite_ref-b_2-0">↑</a></span> <span class="reference-text">other</span>
</li>
</ol></div>
!! end
!! test
Smoke test for duplicated references with conflicting text
!! wikitext
<ref name="a">text</ref>
<ref name="a">bad</ref>
<ref name="b">other</ref>
!! html
<p><sup id="cite_ref-a_1-0" class="reference"><a href="#cite_note-a-1">&#91;1&#93;</a></sup>
<sup id="cite_ref-a_1-1" class="reference"><a href="#cite_note-a-1">&#91;1&#93;</a></sup>
Add a newline in wikitext before autogenerated reflist Previously the reflist was added at the end of the last line of text, which messes up paragraph wrapping (as seen in many test cases), and generated invalid HTML when the last line was a list item (T148701). (second try, previously reverted in 8c933d03c573f7cacf7c385e6fb89d61d6fd7633) Note this affects only pages where the <references /> tag is missing, and the references section is auto-generated at the very end of the page. Bug: T148701 Change-Id: Ib2101346434a4e317b5fc7379215b60c7020cb2b
2020-04-01 22:13:31 +00:00
<sup id="cite_ref-b_2-0" class="reference"><a href="#cite_note-b-2">&#91;2&#93;</a></sup>
Add smoke tests for previously uncovered combinations I noticed a possible issue related to the $this->refSequence counter in the patch Ida9612d. Some of these counters might get messes up, but there was never a test that checked what will happen to the *next* reference then. I checked the test cases in this patch with a very old version of the codebase. Change-Id: If6e56f727dce5d0e5e38e048e602437597248a42
2019-11-27 15:31:53 +00:00
</p>
Add a newline in wikitext before autogenerated reflist Previously the reflist was added at the end of the last line of text, which messes up paragraph wrapping (as seen in many test cases), and generated invalid HTML when the last line was a list item (T148701). (second try, previously reverted in 8c933d03c573f7cacf7c385e6fb89d61d6fd7633) Note this affects only pages where the <references /> tag is missing, and the references section is auto-generated at the very end of the page. Bug: T148701 Change-Id: Ib2101346434a4e317b5fc7379215b60c7020cb2b
2020-04-01 22:13:31 +00:00
<div class="mw-references-wrap"><ol class="references">
Add smoke tests for previously uncovered combinations I noticed a possible issue related to the $this->refSequence counter in the patch Ida9612d. Some of these counters might get messes up, but there was never a test that checked what will happen to the *next* reference then. I checked the test cases in this patch with a very old version of the codebase. Change-Id: If6e56f727dce5d0e5e38e048e602437597248a42
2019-11-27 15:31:53 +00:00
<li id="cite_note-a-1"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-a_1-0">1.0</a></sup> <sup><a href="#cite_ref-a_1-1">1.1</a></sup></span> <span class="reference-text">text <span class="error mw-ext-cite-error" lang="en" dir="ltr">Cite error: Invalid <code>&lt;ref&gt;</code> tag; name "a" defined multiple times with different content</span></span>
</li>
<li id="cite_note-b-2"><span class="mw-cite-backlink"><a href="#cite_ref-b_2-0">↑</a></span> <span class="reference-text">other</span>
</li>
</ol></div>
!! end
!! test
Smoke test for references that are reused *before* defined in the text
Stop formatting "1.2" as "1,2" in languages like German The new extends="…" feature is using numbers like "1.2". These should be localized in languages like Hebrew that uses other symbols for the digits. But the "." should not change. The existing feature when a <ref> is reused multiple times does have the same "issue". But it seems this is intentional, because it is covered by a test. Note this is not visible in German, because German uses custom labels "a", "b", and so on. This patch also improves the so called "smoke" tests and makes one cover numbers up to "1,10" for a <ref> that is reused that often. Bug: T239725 Change-Id: Iffcb56e1c7be09cefed9dabb1d6391eb6ad995ce
2019-12-04 08:10:03 +00:00
!! options
language=de
Add smoke tests for previously uncovered combinations I noticed a possible issue related to the $this->refSequence counter in the patch Ida9612d. Some of these counters might get messes up, but there was never a test that checked what will happen to the *next* reference then. I checked the test cases in this patch with a very old version of the codebase. Change-Id: If6e56f727dce5d0e5e38e048e602437597248a42
2019-11-27 15:31:53 +00:00
!! wikitext
<ref name="a" />
Stop formatting "1.2" as "1,2" in languages like German The new extends="…" feature is using numbers like "1.2". These should be localized in languages like Hebrew that uses other symbols for the digits. But the "." should not change. The existing feature when a <ref> is reused multiple times does have the same "issue". But it seems this is intentional, because it is covered by a test. Note this is not visible in German, because German uses custom labels "a", "b", and so on. This patch also improves the so called "smoke" tests and makes one cover numbers up to "1,10" for a <ref> that is reused that often. Bug: T239725 Change-Id: Iffcb56e1c7be09cefed9dabb1d6391eb6ad995ce
2019-12-04 08:10:03 +00:00
<ref name="a" />
<ref name="a" />
<ref name="a" />
<ref name="a" />
<ref name="a" />
<ref name="a" />
<ref name="a" />
<ref name="a" />
<ref name="a" />
Add smoke tests for previously uncovered combinations I noticed a possible issue related to the $this->refSequence counter in the patch Ida9612d. Some of these counters might get messes up, but there was never a test that checked what will happen to the *next* reference then. I checked the test cases in this patch with a very old version of the codebase. Change-Id: If6e56f727dce5d0e5e38e048e602437597248a42
2019-11-27 15:31:53 +00:00
<ref name="a">text</ref>
<ref name="b">other</ref>
!! html
<p><sup id="cite_ref-a_1-0" class="reference"><a href="#cite_note-a-1">&#91;1&#93;</a></sup>
<sup id="cite_ref-a_1-1" class="reference"><a href="#cite_note-a-1">&#91;1&#93;</a></sup>
Stop formatting "1.2" as "1,2" in languages like German The new extends="…" feature is using numbers like "1.2". These should be localized in languages like Hebrew that uses other symbols for the digits. But the "." should not change. The existing feature when a <ref> is reused multiple times does have the same "issue". But it seems this is intentional, because it is covered by a test. Note this is not visible in German, because German uses custom labels "a", "b", and so on. This patch also improves the so called "smoke" tests and makes one cover numbers up to "1,10" for a <ref> that is reused that often. Bug: T239725 Change-Id: Iffcb56e1c7be09cefed9dabb1d6391eb6ad995ce
2019-12-04 08:10:03 +00:00
<sup id="cite_ref-a_1-2" class="reference"><a href="#cite_note-a-1">&#91;1&#93;</a></sup>
<sup id="cite_ref-a_1-3" class="reference"><a href="#cite_note-a-1">&#91;1&#93;</a></sup>
<sup id="cite_ref-a_1-4" class="reference"><a href="#cite_note-a-1">&#91;1&#93;</a></sup>
<sup id="cite_ref-a_1-5" class="reference"><a href="#cite_note-a-1">&#91;1&#93;</a></sup>
<sup id="cite_ref-a_1-6" class="reference"><a href="#cite_note-a-1">&#91;1&#93;</a></sup>
<sup id="cite_ref-a_1-7" class="reference"><a href="#cite_note-a-1">&#91;1&#93;</a></sup>
<sup id="cite_ref-a_1-8" class="reference"><a href="#cite_note-a-1">&#91;1&#93;</a></sup>
<sup id="cite_ref-a_1-9" class="reference"><a href="#cite_note-a-1">&#91;1&#93;</a></sup>
<sup id="cite_ref-a_1-10" class="reference"><a href="#cite_note-a-1">&#91;1&#93;</a></sup>
Add a newline in wikitext before autogenerated reflist Previously the reflist was added at the end of the last line of text, which messes up paragraph wrapping (as seen in many test cases), and generated invalid HTML when the last line was a list item (T148701). (second try, previously reverted in 8c933d03c573f7cacf7c385e6fb89d61d6fd7633) Note this affects only pages where the <references /> tag is missing, and the references section is auto-generated at the very end of the page. Bug: T148701 Change-Id: Ib2101346434a4e317b5fc7379215b60c7020cb2b
2020-04-01 22:13:31 +00:00
<sup id="cite_ref-b_2-0" class="reference"><a href="#cite_note-b-2">&#91;2&#93;</a></sup>
Add smoke tests for previously uncovered combinations I noticed a possible issue related to the $this->refSequence counter in the patch Ida9612d. Some of these counters might get messes up, but there was never a test that checked what will happen to the *next* reference then. I checked the test cases in this patch with a very old version of the codebase. Change-Id: If6e56f727dce5d0e5e38e048e602437597248a42
2019-11-27 15:31:53 +00:00
</p>
Add a newline in wikitext before autogenerated reflist Previously the reflist was added at the end of the last line of text, which messes up paragraph wrapping (as seen in many test cases), and generated invalid HTML when the last line was a list item (T148701). (second try, previously reverted in 8c933d03c573f7cacf7c385e6fb89d61d6fd7633) Note this affects only pages where the <references /> tag is missing, and the references section is auto-generated at the very end of the page. Bug: T148701 Change-Id: Ib2101346434a4e317b5fc7379215b60c7020cb2b
2020-04-01 22:13:31 +00:00
<div class="mw-references-wrap"><ol class="references">
Stop formatting "1.2" as "1,2" in languages like German The new extends="…" feature is using numbers like "1.2". These should be localized in languages like Hebrew that uses other symbols for the digits. But the "." should not change. The existing feature when a <ref> is reused multiple times does have the same "issue". But it seems this is intentional, because it is covered by a test. Note this is not visible in German, because German uses custom labels "a", "b", and so on. This patch also improves the so called "smoke" tests and makes one cover numbers up to "1,10" for a <ref> that is reused that often. Bug: T239725 Change-Id: Iffcb56e1c7be09cefed9dabb1d6391eb6ad995ce
2019-12-04 08:10:03 +00:00
<li id="cite_note-a-1"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-a_1-0">1,00</a></sup> <sup><a href="#cite_ref-a_1-1">1,01</a></sup> <sup><a href="#cite_ref-a_1-2">1,02</a></sup> <sup><a href="#cite_ref-a_1-3">1,03</a></sup> <sup><a href="#cite_ref-a_1-4">1,04</a></sup> <sup><a href="#cite_ref-a_1-5">1,05</a></sup> <sup><a href="#cite_ref-a_1-6">1,06</a></sup> <sup><a href="#cite_ref-a_1-7">1,07</a></sup> <sup><a href="#cite_ref-a_1-8">1,08</a></sup> <sup><a href="#cite_ref-a_1-9">1,09</a></sup> <sup><a href="#cite_ref-a_1-10">1,10</a></sup></span> <span class="reference-text">text</span>
Add smoke tests for previously uncovered combinations I noticed a possible issue related to the $this->refSequence counter in the patch Ida9612d. Some of these counters might get messes up, but there was never a test that checked what will happen to the *next* reference then. I checked the test cases in this patch with a very old version of the codebase. Change-Id: If6e56f727dce5d0e5e38e048e602437597248a42
2019-11-27 15:31:53 +00:00
</li>
<li id="cite_note-b-2"><span class="mw-cite-backlink"><a href="#cite_ref-b_2-0">↑</a></span> <span class="reference-text">other</span>
</li>
</ol></div>
!! end
!! test
Smoke test for references that are reused *before* defined in <references>
!! wikitext
<ref name="a" />
<ref name="a" />
<ref name="b">other</ref>
<references>
<ref name="a">text</ref>
</references>
!! html
<p><sup id="cite_ref-a_1-0" class="reference"><a href="#cite_note-a-1">&#91;1&#93;</a></sup>
<sup id="cite_ref-a_1-1" class="reference"><a href="#cite_note-a-1">&#91;1&#93;</a></sup>
<sup id="cite_ref-b_2-0" class="reference"><a href="#cite_note-b-2">&#91;2&#93;</a></sup>
</p>
<div class="mw-references-wrap"><ol class="references">
<li id="cite_note-a-1"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-a_1-0">1.0</a></sup> <sup><a href="#cite_ref-a_1-1">1.1</a></sup></span> <span class="reference-text">text</span>
</li>
<li id="cite_note-b-2"><span class="mw-cite-backlink"><a href="#cite_ref-b_2-0">↑</a></span> <span class="reference-text">other</span>
</li>
</ol></div>
!! end
Integration parser test for ParserFunctions Depends-On: I09844079f163e583d3b1e941c701f8cda5029a0a Bug: T240345 Change-Id: I86c55ff88d9f4b800e8868728dfec6b4ceda82c2
2019-12-11 07:58:17 +00:00
Add test cases for impossible follow vs. rollback edge case While working on the patch I4303642 I was worried about the line array_pop( $this->refCallStack ) in the rollback code. Since the patch changed the position of follow elements in the stack, an array_pop() would pop different elements. It turns out this is impossible. Rollbacks are only done for <ref> elements inside a <references> tag, immediatelly after reaching the closing </references>. It's impossible to use follow="…" inside <references>. It will not be added to the stack, and therefore not rolled back. Even if the edge case would be possible, the *old* code that placed follow elements on the *other* side of the stack would have been wrong then. The test cases in this patch try to hit this edge case, and are expected to not be able to do so. Change-Id: I4380bf443db17c6214dbfa2cbda62b46db04258a
2020-04-01 08:37:08 +00:00
!! test
It should be impossible to roll back a follow="…", because it can't have a name
!! wikitext
<ref name="a" />
<ref name="b">should be 2</ref>
<references>
<ref name="a">should be 1</ref>
<ref name="c" follow="other page">is invalid</ref>
</references>
!! html
<p><sup id="cite_ref-a_1-0" class="reference"><a href="#cite_note-a-1">&#91;1&#93;</a></sup>
<sup id="cite_ref-b_2-0" class="reference"><a href="#cite_note-b-2">&#91;2&#93;</a></sup>
</p>
<div class="mw-references-wrap"><ol class="references">
<li id="cite_note-a-1"><span class="mw-cite-backlink"><a href="#cite_ref-a_1-0">↑</a></span> <span class="reference-text">should be 1</span>
</li>
<li id="cite_note-b-2"><span class="mw-cite-backlink"><a href="#cite_ref-b_2-0">↑</a></span> <span class="reference-text">should be 2</span>
</li>
</ol></div>
Give a different error from too_many_keys when 'follow' attribute conflicts Add message "cite_error_ref_follow_conflicts" for tags with conflicting parameters. Bug: T299280 Change-Id: Ie64f4ab4831966f66f812ea67cc244718f818afb
2022-05-27 06:27:10 +00:00
<p><span class="error mw-ext-cite-error" lang="en" dir="ltr">Cite error: A <code>&lt;ref follow="…"&gt;</code> tag that is the continuation of a previous one can neither be named individually nor extended</span>
Add test cases for impossible follow vs. rollback edge case While working on the patch I4303642 I was worried about the line array_pop( $this->refCallStack ) in the rollback code. Since the patch changed the position of follow elements in the stack, an array_pop() would pop different elements. It turns out this is impossible. Rollbacks are only done for <ref> elements inside a <references> tag, immediatelly after reaching the closing </references>. It's impossible to use follow="…" inside <references>. It will not be added to the stack, and therefore not rolled back. Even if the edge case would be possible, the *old* code that placed follow elements on the *other* side of the stack would have been wrong then. The test cases in this patch try to hit this edge case, and are expected to not be able to do so. Change-Id: I4380bf443db17c6214dbfa2cbda62b46db04258a
2020-04-01 08:37:08 +00:00
</p>
!! end
!! test
It should be impossible to roll back a follow="…", because it must have a name
!! wikitext
<ref name="a" />
<ref name="b">should be 2</ref>
<references>
<ref name="a">should be 1</ref>
<ref follow="other page">is invalid</ref>
</references>
!! html
<p><sup id="cite_ref-a_1-0" class="reference"><a href="#cite_note-a-1">&#91;1&#93;</a></sup>
<sup id="cite_ref-b_2-0" class="reference"><a href="#cite_note-b-2">&#91;2&#93;</a></sup>
</p>
<div class="mw-references-wrap"><ol class="references">
<li id="cite_note-a-1"><span class="mw-cite-backlink"><a href="#cite_ref-a_1-0">↑</a></span> <span class="reference-text">should be 1</span>
</li>
<li id="cite_note-b-2"><span class="mw-cite-backlink"><a href="#cite_ref-b_2-0">↑</a></span> <span class="reference-text">should be 2</span>
</li>
</ol></div>
<p><span class="error mw-ext-cite-error" lang="en" dir="ltr">Cite error: <code>&lt;ref&gt;</code> tag defined in <code>&lt;references&gt;</code> has no name attribute.</span>
</p>
!! end
Reference in a new issue Copy permalink