Content deleted Content added
→great and powerful script: new section |
|||
| (32 intermediate revisions by 11 users not shown) | |||
Line 21:
:{{replyto|Tgr}} didn't have time to fully read it, would it be much work on the test cases to convert them to your new module ? —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 20:53, 4 June 2013 (UTC)
: I created [[Module:UnitTests/sandbox]] which right now only mixes logic and presentation in three places. I created [[Module talk:Citation/CS1/testcases2]] to make sure it still works and for comparison purposes. testcases2 uses 6.91 MB of memory and takes 3.964 seconds to process tests compared to testcases which uses 7.23 MB of memory and takes 4.933 seconds to process tests. Maybe with full separation of the logic and presentation the memory footprint and processing time can be decreased further. I think another approach to unit testing would be better, but that will require rewriting current tests, which like in the case of the citation module, could take a bit of effort to do. --<span style="font: bold 10pt 'courier new', comic, sans, ms;">[[User:Darklama|<
== Test a string contains expected text ==
Line 41:
Why ''{<!-- -->{#invoke:UnitTests/testcases/frame | _test}}'' give [[Module talk:UnitTests/testcases|different result]] for direct #invoke vs. invoke via UnitTests module?
--[[User:Ans|Ans]] ([[User talk:Ans|talk]]) 13:58, 11 October 2017 (UTC)
== templatestyles ==
[[Module:Citation/CS1]] supports some 25 live templates and [[Module:Citation/CS1/sandbox]] supports an equal number of sandbox templates. We could have added [[WP:TemplateStyles]] markup ({{tag|templatestyles|params=src="<{{var|name}}>/styles.css"|s}}) 25× to the live templates and 25× to the sandboxen but that just seemed dumb so each of the modules concatenate template styles to the end of the cs1|2 template rendering using this (where <code>styles</code> is the name of the appropriate css page):
:<syntaxhighlight lang="lua">frame:extensionTag ('templatestyles', '', {src=styles})})</syntaxhighlight>
and that works great.
Except in [[Module:Citation/CS1/testcases]].
Where every test fails. 318 failures. There are differences between the live and sandbox modules but not that many.
Because of TemplateStyles. Why? Because TemplateStyles inserts a stripmarker at the end of every cs1|2 template rendering and each stripmarker has a unique id number. So, this always fails:
:<code><nowiki>{{#ifeq:{{cite book |title=Title}}|{{cite book |title=Title}}|ok|FAIL}}</nowiki></code>
::{{#ifeq:{{cite book |title=Title}}|{{cite book |title=Title}}|ok|FAIL}}
even though the two {{tlx|cite book}} templates are identically written.
Here are two transclusions of identical templates; note the stripmakers at the ends:
:{{code|{{cite book|title}}}}
:{{code|{{cite book|title}}}}
To get round this, I have hacked [[Module:UnitTests]] function <code>preprocess_equals_preprocess()</code> (called only by <code>preprocess_equals_preprocess_many()</code>) to accept a new <code>option.templatestyles</code>. When that option is set to <code>true</code>, the code looks at the content of <code>expected</code> and extracts the <code>templatestyles</code> stripmarker identifier (an 8-digit hex number). It then overwrites the <code>templatestyles</code> stripmarker identifier in <code>actual</code> so that they both have the same identifier. Only then does <code>preprocess_equals_preprocess()</code> compare <code>actual</code> against <code>expected</code>.
If you are looking to text changes in ~/sandbox/styles.css compared to ~/styles.css, this change won't help you – and Module:UnitTest is probably the wrong tool anyway because stripmarkers are replaced with their actual content after this module has run.
I suppose that there might be reasons that we might want to expand the capabilities of this functionality though I'm not sure just what those reasons might be. For example these possibilities:
:<code>none</code> – remove <code>templatestyles</code> stripmarkers from both <code>actual</code> and <code>expected</code>; no styling applied to the renderings
:<code>actual</code> – replace <code>templatestyles</code> stripmarker identifier in <code>expected</code> with the <code>templatestyles</code> stripmarker identifier from <code>actual</code>; both use ~/sandbox/styles.css for styling
Perhaps there are others.
—[[User:Trappist the monk|Trappist the monk]] ([[User talk:Trappist the monk|talk]]) 19:27, 28 March 2019 (UTC)
:Good work, life is getting complicated! [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 23:14, 28 March 2019 (UTC)
== Table of Contents ==
What about generating a table of contents? [[User:Trigenibinion|Trigenibinion]] ([[User talk:Trigenibinion|talk]]) 14:54, 12 March 2021 (UTC)
== Conflicts with 'Module:No globals' ==
A handful of functions in this module are not marked 'local', but could and (arguably) should be. --[[Special:Contributions/86.143.105.15|86.143.105.15]] ([[User talk:86.143.105.15|talk]]) 10:36, 27 January 2022 (UTC)
== Tests not failing when they should ==
I'm creating testcases for [[Module:GetShortDescription]] and [[Module:Annotated link]] and due to my own derping, left some copy-pasta typos which should have caused a series of tests to fail, but they did not. I fixed the typos but [[Special:Diff/1135864158/1135864279|purposefully altered one test to fail]] and it sailed through running <code><nowiki>{{#invoke:AnnotatedLink/testcases|run_tests}}</nowiki></code>. Am I doing something wrong, or is there a problem with this module? <code style="background:#DFF;white-space:pre">[[User:Fred Gandt|Fred Gandt]] · [[User talk:Fred Gandt|talk]] · [[Special:Contributions/Fred Gandt|contribs]]</code> 09:42, 27 January 2023 (UTC)
:"Test methods like test_hello above must begin with 'test'". I knew that. <code style="background:#DFF;white-space:pre">[[User:Fred Gandt|Fred Gandt]] · [[User talk:Fred Gandt|talk]] · [[Special:Contributions/Fred Gandt|contribs]]</code> 09:45, 27 January 2023 (UTC)
:Might I suggest not outputting "All tests passed." when no tests have been run? <code style="background:#DFF;white-space:pre">[[User:Fred Gandt|Fred Gandt]] · [[User talk:Fred Gandt|talk]] · [[Special:Contributions/Fred Gandt|contribs]]</code> 11:18, 27 January 2023 (UTC)
::{{done}}. I've also included the total amount of tests ran in general. [[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 11:49, 27 January 2023 (UTC)
:::Very nifty; thank you 😊 <code style="background:#DFF;white-space:pre">[[User:Fred Gandt|Fred Gandt]] · [[User talk:Fred Gandt|talk]] · [[Special:Contributions/Fred Gandt|contribs]]</code> 13:01, 27 January 2023 (UTC)
== Allow nowiki option to have three states ==
Currently it appears that <code>nowiki</code> is a boolean option; could we have a third option to display both the {{tag|nowiki}} and parsed results? We could of course double all tests where this might be desirable, but 1) they might not end up anywhere near each other, and 2) it'd be inefficient. Suggest: <code>{nowiki = 2}</code> (semantically nice and easy math) for the third state. <code style="background:#DFF;white-space:pre">[[User:Fred Gandt|Fred Gandt]] · [[User talk:Fred Gandt|talk]] · [[Special:Contributions/Fred Gandt|contribs]]</code> 20:36, 27 January 2023 (UTC)
:For the sake of ease in handling the code, and the fact I'd rather keep those options as just "truthy" checks instead of exact == checks (the only reason its <code>=1</code> in the doc is probably because its shorter than typing <code>=true</code>), does something like a seperate <code>nowikiplus</code> or <code>combined</code> option sound better? I'll probably have to standardise the module a little to make adding this not mean pasting the same code in 5 different functions, but it should be doable (I'll just have to think about how to lay it out in the output). [[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 09:37, 28 January 2023 (UTC)
::Sounds good to me! Definitely think of the maintainability of the code ahead of the minor convenience of only having one option to consider. Personally; I think <code>combined</code> is better. Thank you for your consideration 😊 <code style="background:#DFF;white-space:pre">[[User:Fred Gandt|Fred Gandt]] · [[User talk:Fred Gandt|talk]] · [[Special:Contributions/Fred Gandt|contribs]]</code> 09:46, 28 January 2023 (UTC)
:::{{ping|Fred Gandt}} I've managed to get some initial work done on this (currently got the main functions <code>preprocess_equals(_many)</code> and <code>preprocess_equals_preprocess(_many)</code> running under the new system idea in the sandbox) - Does the format I've given seen fine in your testcases? I don't want to start working on the more complicated to convert functions unless it's all working fine. You can test these by changing <code>require('Module:UnitTests')</code> to <code>require('Module:UnitTests/sandbox')</code> and specifying <code>combined</code> instead of <code>nowiki</code>. [[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 14:41, 28 January 2023 (UTC)
::::Really; that looks great! Very neat table organisation. I hope all your effort is appreciated by more than just me, but rest assured I am impressed. Seeing the raw markup is great for technical analysis, but seeing the result is great for rapid detection of issues. Having them side by side (well over and under but same thing) like that is a quality of life improvement. Thank you 😊 <code style="background:#DFF;white-space:pre">[[User:Fred Gandt|Fred Gandt]] · [[User talk:Fred Gandt|talk]] · [[Special:Contributions/Fred Gandt|contribs]]</code> 16:07, 28 January 2023 (UTC)
== Present failed tests together at the top ==
Another suggestion: present all failed tests at the top of the results. This might be achieved multiple ways and someone with greater familiarity with the code might be best suited to decide exact what approach is best. As a user; seeing two sections – the uppermost for failed and the next for passed tests – would be ideal. Section depth should be unimportant unless the results are substed (but who would do that?); lvl 3 sections should be fine since the whole lot can be placed under a standard lvl 2 section for posterity. Diverting the results as their condition becomes known to the appropriate section should be trivial (easy for me to say right? I'm a tad busy right now but will tackle it myself if necessary). <code style="background:#DFF;white-space:pre">[[User:Fred Gandt|Fred Gandt]] · [[User talk:Fred Gandt|talk]] · [[Special:Contributions/Fred Gandt|contribs]]</code> 09:24, 28 January 2023 (UTC)
:I'll try theory this in the sandbox too. [[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 09:37, 28 January 2023 (UTC)
::I will prepare a WikiLove goat for you! Seriously though; thanks again for you consideration ❤ <code style="background:#DFF;white-space:pre">[[User:Fred Gandt|Fred Gandt]] · [[User talk:Fred Gandt|talk]] · [[Special:Contributions/Fred Gandt|contribs]]</code> 09:46, 28 January 2023 (UTC)
::Some wild yellow backgrounds have appeared 👀 😉 <code style="background:#DFF;white-space:pre">[[User:Fred Gandt|Fred Gandt]] · [[User talk:Fred Gandt|talk]] · [[Special:Contributions/Fred Gandt|contribs]]</code> 16:13, 28 January 2023 (UTC)
:::Ooooh yes, forgot I implemented that. There was a feature only in preprocess_equals_preprocess where failed tests were highlighted orange/yellow so they were easier to spot - I decided to give it a test run in the sandbox to make it apply the highlighting to more functions and completely forgot I did so. I'll probably make it an opt-in argument of the <code>#invoke:</code> (maybe <code>|highlight=</code>, a bit like <code>|differs_at=</code>).
::::<small>(changed to an invoke option - [[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 16:43, 28 January 2023 (UTC))</small>
:::Oh, and I'm currently working on doing the split of failed and successful results from above, though I'm gonna have to think about how to do multi tests if they fail in the middle (I'm not sure they split too well right now, but we'll see). [[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 16:32, 28 January 2023 (UTC)
::::I understand and fully appreciate how complex it is; there's no hurry or even need for this nice-to-have feature request. Don't forget to have a good day while you're working on it. <code style="background:#DFF;white-space:pre">[[User:Fred Gandt|Fred Gandt]] · [[User talk:Fred Gandt|talk]] · [[Special:Contributions/Fred Gandt|contribs]]</code> 16:44, 28 January 2023 (UTC)
:::::Alright, I've decided ''not'' to implement the splitting with headers - screwing with the positional layout, especially with functions that do multiple checks in one run, is a bit more complicated and finicky than I think it's worth. Hopefully the highlight feature helps enough with finding the errors enough in that regard. As for everything else, I'll be moving that from the sandbox version to the live version some point soon when im free, and I'll also make sure to update the doc page (it's missing both the new stuff and some already existing stuff). [[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 18:56, 28 January 2023 (UTC)
::::::Understood. I hope it didn't trouble you too much trying, and again, I really appreciate the effort. I made a little helper script, [[User:Fred Gandt/moveFailedModuleTestsToTop.js|moveFailedModuleTestsToTop.js]], that shifts all the failures to the top on load. It's dirt simple and could do with extra qualification; would you mind if the tables include something like <code>class="wikitable module-unit-tests-result"</code> so the script can be more particular? I nearly went ahead and stuck it in there myself, but considered that might be a bit rude. I should have the script to pick out sets of tables where results of multiple invocations are present... <code style="background:#DFF;white-space:pre">[[User:Fred Gandt|Fred Gandt]] · [[User talk:Fred Gandt|talk]] · [[Special:Contributions/Fred Gandt|contribs]]</code> 01:51, 29 January 2023 (UTC)
:::::::Don't worry about any trouble I had doing this, coding is a big hobby of mine and I enjoy fixing up stuff like this. I've gone ahead and added the class to the table headers and called it <code>unit-tests-result</code>. I don't think it would've been rude to add the class yourself, it's a simple minor improvement and it doesn't screw with the existing layout, so it's completely fine. [[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 06:07, 29 January 2023 (UTC)
::::::::Many thanks again 😊 I know what you mean; I love coding too. I hoping one day to be good at it 😉 <code style="background:#DFF;white-space:pre">[[User:Fred Gandt|Fred Gandt]] · [[User talk:Fred Gandt|talk]] · [[Special:Contributions/Fred Gandt|contribs]]</code> 07:48, 29 January 2023 (UTC)
== ID fix for all strip markers ==
@[[User:Pppery|Pppery]] Hello, I noticed you reverted my edit. Could you share an example of a test that should be failing passing. Thanks, <span class="nowrap">– [[User:BrandonXLF|<span style="color:blue;">Brandon</span><span style="color:green;">XLF</span>]] ([[User talk:BrandonXLF|talk]])</span> 16:34, 25 May 2023 (UTC)
: The case that brought this to my attention was [[Module talk:YouTubeSubscribers/testcases]], but AFAIK any test using preprocess_equals to compare unequal strings should trigger the bug. [[User:Pppery|* Pppery *]] [[User talk:Pppery|<sub style="color:#800000">it has begun...</sub>]] 16:37, 25 May 2023 (UTC)
::I've reimplemented the stripping for the expected with the bug hopefully fixed (the expected was accidentally replaced with the actual, causing it to just see if equals itself). [[User:Aidan9382|Aidan9382]] <sub>([[User talk:Aidan9382|talk]])</sub> 17:04, 25 May 2023 (UTC)
:::Oh I didn't catch that, thanks! <span class="nowrap">– [[User:BrandonXLF|<span style="color:blue;">Brandon</span><span style="color:green;">XLF</span>]] ([[User talk:BrandonXLF|talk]])</span> 23:17, 25 May 2023 (UTC)
== great and powerful script ==
congratulations ! Thanks. -- [[User:Wladek92|Wladek92]] ([[User talk:Wladek92|talk]]) 08:43, 16 June 2025 (UTC)
| |||