Module talk:Template test case

Multiple automatic sandbox versions

Can we please extend the automatic addition of a /sandbox variant to all _templateis if there is no _template++i? — Christoph Päper 11:14, 20 September 2019 (UTC)

Table with many tests

For some templates, especially inline templates like {{frac}}, it makes sense to have all or most test cases in a single table with one combination of parameters per row. It would be nice if this could be handled by a single function call by passing multiple parameter sets, e.g.:

{{test case|_template1=frac|_template3=sfrac
|_test1={1}      |_label1=single anonymous parameter, numeric
|_test2={1,2}    |_label2=two anonymous parameters, all numeric
|_test3={1,2,3}  |_label3=three anonymous parameters, all numeric
|_test4={1=1}    |_label4=single, first parameter
|_test5={2=1}    |_label5=single, second parameter
|_test6={3=1}    |_label6=single, third parameter
|_test7={1,3=2}  |_label7=first and third parameter
|_test8={2=1,3=2}|_label8=second and third parameter
|_test9={a}      |_label9=single anonymous parameter, alphabetic
|_test10={1,1}   |_label10=two equal parameters
}}

11:14, 20 September 2019 (UTC)

Alternatively, there should be an additional rendering mode cells. It would put the code and each result for all templates and sandbox versions into adjacent cells in a single table row, but the user would have to provide the surrounding table code (but possibly not the rows |-). — Christoph Päper 10:16, 1 January 2020 (UTC)

{| class="wikitable sortable"
|+ Test cases
|-
! Test case description !! Template call 
! {{tl|frac}} !! {{tl|frac/sandbox}} !! {{tl|sfrac}} !! {{tl|sfrac/sandbox}}
|-
{{test case|_format=cells|_template1=frac|_template3=sfrac|1|_label=single anonymous parameter, numeric}}
{{test case|_format=cells|_template1=frac|_template3=sfrac|1|2|_label=two anonymous parameters, all numeric}}
{{test case|_format=cells|_template1=frac|_template3=sfrac|1|2|3|_label=three anonymous parameters, all numeric}}
{{test case|_format=cells|_template1=frac|_template3=sfrac|1=1|_label=single, first parameter}}
{{test case|_format=cells|_template1=frac|_template3=sfrac|2=1|_label=single, second parameter}}
{{test case|_format=cells|_template1=frac|_template3=sfrac|3=1|_label=single, third parameter}}
{{test case|_format=cells|_template1=frac|_template3=sfrac|1|3=2|_label=first and third parameter}}
{{test case|_format=cells|_template1=frac|_template3=sfrac|2=1|3=2|_label=second and third parameter}}
{{test case|_format=cells|_template1=frac|_template3=sfrac|a|_label=single anonymous parameter, alphabetic}}
{{test case|_format=cells|_template1=frac|_template3=sfrac|1|1|_label=two equal parameters}}
|}

Hyphen issue in Template:Test case nowiki

This came up when I was working on Template:Graphical timeline/testcases. At Special:Permalink/958740301 it can be observed that parameter |note3-at= gets a broken value. First character, hyphen, is correct, however, the first opening brace { of {{Period start}} is converted into an HTML entity for some reason. This results in an error Expression error: Unrecognized punctuation character "&" somewhere deep inside the template's internals. I've added a test case to demonstrate the issue on a smaller example. —⁠andrybak (talk) 13:38, 25 May 2020 (UTC)

See phab:T168759 * Pppery * _{it has begun...} 20:45, 25 May 2020 (UTC)

Something just changed

Moved to Wikipedia:Village pump (technical) § Audio player doesn't work inside collapsed templates

From yesterday to today, the boxes at Template:Spoken Wikipedia/testcases changed from yellow to green, became collapsed, and introduced an error where they now don't seem to be able to embed audio files properly. I'm not sure where the edit that caused this was made, though. Does anyone know? {{u|Sdkb}} ^talk 21:20, 9 July 2020 (UTC)

Sdkb, user Izno has responded to the edit request. That would explain the change from yellow to green on /testcases. Templates {{Spoken Wikipedia}} and {{Spoken Wikipedia/sandbox}} now produce the same output. Audio player is also broken for me. —⁠andrybak (talk) 22:13, 9 July 2020 (UTC)

I've changed the output of /sandbox, and the audio players are now fixed. Perhaps the player doesn't survive in a collapsed state? —⁠andrybak (talk) 22:17, 9 July 2020 (UTC)

Andrybak, hmm, interesting. I just checked a few live instances, and it's not causing any problems there. {{u|Sdkb}} ^talk 22:18, 9 July 2020 (UTC)

(edit conflict)

Tests for media player

Collapsed	Not collapsed
Audio player inside
Video player inside

Audio player is broken, but video is fine. —⁠andrybak (talk) 22:18, 9 July 2020 (UTC)

Sdkb, I suggest to move this discussion to WP:VPT. Module:Template test case is not at fault, it's wider issue. —⁠andrybak (talk) 22:23, 9 July 2020 (UTC)

How to specify page name?

I looked through the documentation, but I was unable to find a way to specify the page name (magic word PAGENAME) in a template test case. For templates that use Wikidata calls, for example, the Wikidata call checks the PAGENAME and retrieves the appropriate bit of data from the corresponding Wikidata page. Is there a way to do this? The result would be to render the template as it would appear when processed by Special:ExpandTemplates with the appropriate PAGENAME entered in the upper text field. – Jonesey95 (talk) 22:55, 23 July 2020 (UTC)

Partial answer, still looking for a real answer: A possible workaround is to use |qid= in your infobox. See Template:Ordination/testcases for an example. – Jonesey95 (talk) 01:23, 3 August 2020 (UTC)

I don't think this is possible. * Pppery * _{it has begun...} 02:24, 4 August 2020 (UTC)

Paragraph break when using {{inline test case}}

This is probably something silly I am doing, but I can't figure out what. I am using {{inline test case}} in the testcase page of Template:Cite certification and from some reason I am sometimes (rarely) getting an extra paragraph break between results. I created an example: Template:Cite certification/testcases-example. I was worried that there is something wrong with the {{Cite certification}}, but as you can see from the code in the example, the paragraph break does not appear when running either the stable or the (identical) sandbox versions. Any ideas? --Muhandes (talk) 14:46, 31 December 2020 (UTC)

There was an invisible character (a Left-to-right mark) on your testcases example page. I copied the whole page to a text editor, told it to show the invisible characters, and deleted it. – Jonesey95 (talk) 16:51, 31 December 2020 (UTC)

Thanks, I must have wasted five hours of my time finding that one. I now have a good way to test it in the future. --Muhandes (talk) 19:36, 31 December 2020 (UTC)

Sandbox2, Test case2, and wrapperConfig

I'd like the ability to use a second sandbox, say, 'sandbox2', to enable simultaneous testing of different sets of changes in parallel tracks for the same template. Having browsed Module:Template test case, I believe a better method is available than the obvious brute force method of duplicating template FOO to FOO2, then FOO2/sandbox, and testcases to FOO2/testcases. Afaict the key seems to have something to do with wrapperConfig unless I'm mistaken, only I don't see how to use it, and the /doc doesn't have much to say about it.

This use case comes up occasionally in RL on complex templates that may need extended testing of some feature, while someone else desires to test another feature, or where different scenarios are being tried out. (For a RW case of the former type see Template talk:Find sources#Missing redirect detection bug.) I get the feeling I can just create Template:Find sources/sandbox2 with my changes, and then create a "wrapper config" somewhere, and set it as param2 to the invoke.

For example, can I just duplicate Module:Template test case/config to Template:Find general sources/MySandbox2Config, edit it to set sandboxSubpage = 'sandbox2', and then in Template:Find general sources/sandbox2 invoke like this: {{#invoke:Find sources|Find general sources, MySandbox2Config}}? Or am I misconstruing how this is supposed to work, and I should go back to the brute force method? Or something else? Pinging @Mr. Stradivarius and Trialpears:.

Either way, param2 of the module appears to be a config of some kind, so whether my assumptions above are right or wrong, it would be nice if someone could add a == Params == section to Module:Template test case/doc to describe what this param is and how to use it. (please  mention me on reply; thanks!) Mathglot (talk) 22:28, 25 December 2021 (UTC)

@Mathglot: You can use a second sandbox by setting the |_template1=, |_template2= and |_template3= arguments. For example, {{test case|_template1=Find sources|_template2=Find sources/sandbox|_template3=Find sources/sandbox2|Foo}} outputs the following:

{{test case|_template1=Find sources|_template2=Find sources/sandbox|_template3=Find sources/sandbox2|Foo}}

The module is built so that the default value for _template1 is the base page of the current page, and the default value for _template2 is its sandbox subpage. In fact, if you are calling the module from Template:Find sources/testcases, you could omit the |_template1= and |_template2= arguments, and just specify |_template3=Find sources/sandbox2 to get the same results. — Mr. Stradivarius ^{♪ talk ♪} 01:17, 26 December 2021 (UTC)

As for the config file, this is not intended to be specified by users. I believe I allowed the config to be passed to the main function so that it can be more easily tested, but this ability is not currently used by Module:Template test case/testcases. I probably only used it in the console during initial development. Also, the config cannot be passed from wikitext; it needs to be passed from another Lua module. From wikitext you can only influence the contents of the first parameter (the frame object) to the function called from #invoke; you can't influence the contents of subsequent parameters. — Mr. Stradivarius ^{♪ talk ♪} 01:45, 26 December 2021 (UTC)

Thanks, Mr. Stradivarius, this was very helpful. Mathglot (talk) 17:26, 26 December 2021 (UTC)

format=columns + inline hybrid

I've a bunch of test cases for a template that takes lots of complicated parameters, but whose output is a relatively short text. Think {{cite book}} and you're in the ballpark. I want to see the code up top in a nowiki block like {{test case nowiki|format=columns}} or |format=rows gives me, but I'd like to see the output arranged vertically like {{test case nowiki|format=inline}} gives me.

Something like:

Example of desired output
{{example |first-argument = has a value |second-argument = does too |veni-vidi-vici = yes |lipsum = lorem }} Veni, vidi, vici Lorem ipsum dolor sit amet

Any takers? Mr. Stradivarius? --Xover (talk) 08:45, 13 January 2023 (UTC)

{{Testcase table}} with |_format=? – Jonesey95 (talk) 22:26, 14 January 2023

Example:

{{code}}

{{code|foo}}

foo

foo

How's that? You can tweak the underscore parameters to your liking. – Jonesey95 (talk) 23:34, 14 January 2023 (UTC)

Thanks. That's a nice option, but I kinda prefer the interface for {{test case nowiki}} for this (it's clearer, and with less faffing and things that can go wrong when converting something found in the wild into a test case). --Xover (talk) 19:33, 15 January 2023 (UTC)

Use of _before and _after

I'm trying to use the |_before= parameter, mostly to have something to hange templates that create superscript references, tags, and that sort of thing, so they don't appear to be isolated in space. What I'd like to see in this example, is something like this:

Some text to hang a tag on.

Here's my test case, using |_before=:

{{Citation needed}}

Some text to hang a tag on.

{{Citation needed/sandbox}}

Some text to hang a tag on.

Am I doing something wrong, here? Why isn't it echoing the "before" text? Mathglot (talk) 04:29, 26 January 2023 (UTC)

@Mathglot: You aren't doing anything wrong. It seems the _before (and _after) option wasn't implemented for all render (_format) methods (There's 5, which are columns, rows, inline, cells, and default - only columns and cells considered _before, and your example renders in default since nothing was specified). I've implemented the code into the other render formats, so it should start displaying now. Aidan9382 _(talk) 07:10, 26 January 2023 (UTC)

Aidan9382 And, indeed it is! I noticed it working on one of my testcase pages, before I even saw my notification alert icon change color. Any faster, and I'd have to give you the faster-than-light barnstar ; thanks so much! (For the curious: the example above used to show nothing but tags, and no text; but since Aidan's fix, is now working properly.) Mathglot (talk) 07:21, 26 January 2023 (UTC)

Template use when there's no sandbox

@Frietjes, re this edit, should we make some change to {{Test case}} to better handle instances when it's used when there's no sandbox? {{u|Sdkb}} ^talk 19:42, 19 May 2023 (UTC)

Sdkb, maybe, or you could just create a sandbox version. Frietjes (talk) 19:43, 19 May 2023 (UTC)

True. In that case, I was just looking to see whether the template could handle a particular use case, not to make changes to it, so all I needed was the testcases page. {{u|Sdkb}} ^talk 19:46, 19 May 2023 (UTC)

I always just click the "mirror" link in the template doc when the sandbox does not exist. It takes two clicks total to create a working sandbox. – Jonesey95 (talk) 15:14, 21 May 2023 (UTC)

Using syntaxhighlight when _showcode is used

I've changed the <code>...</code> tags to <syntaxhighlight>...</syntaxhighlight> tags when |_showcode= is used. Sandbox and Diff. Gonnym (talk) 18:04, 23 May 2023 (UTC)

Hmm. Would it make sense to have that be opt-in, at least initially, by adding a new |format=syntaxhighlight (and/or |format=syntax maybe) instead? Are there any weird border cases where <code><nowiki>...</nowiki></code> works, but <syntaxhighlight lang="mediawiki" inline>...</syntaxhighlight> might break? FeRDNYC (talk) 04:00, 15 July 2023 (UTC)

Inconsistency between Test case nowiki and others

So, in most of the test case templates, you pass arguments to the test-case code preceded by underscores, and actual arguments to the template being tested are passed as usual, e.g.:

{{Test case|_collapsible=yes|_showcode=yes|_title=Some test case
|_template1=Code
|1=wikitable
}}

OK, great. But then here comes {{Test case nowiki}}, where the underscore arguments don't work, and you have to use non-underscored ones:

BAD

{{Test case nowiki|_collapsible=yes|_showcode=yes|_title=Some test case
|_template1=Code
|<nowiki>{{__TEMPLATENAME__
|1=wikitable}}</nowiki>
}}

Works

{{Test case nowiki|collapsible=yes|showcode=yes|title=Some test case
|template1=Code
|<nowiki>{{__TEMPLATENAME__
|1=wikitable}}</nowiki>
}}

My question is, why??? If these templates are a "family", and so often used together, doesn't it make sense for {{Test case nowiki}} to take the same set of arguments that {{Test case}} and all the others take? Even if it's not strictly necessary for them to be preceded by underscores? It would make converting test cases between the non-nowiki and nowiki versions a lot quicker and more convenient. Am I really the only person who finds themselves doing that pretty frequently? FeRDNYC (talk) 06:33, 15 July 2023 (UTC)

The technical reason for why comes down to this bit of code, in which the nowiki wrapper has its arguments done differently. The reason I think this was done in practice is because the only reason the underscores are used in the {{Test case}} version is because you have to provide the real arguments, so prefixing the options with _ prevents conflicts. Since the nowiki version just takes the parameter 1, it had no need for the underscores. Aidan9382 _(talk) 06:57, 15 July 2023 (UTC)

*nod* I totally understand why the _-prefixed arguments are needed for the other templates, and why {{Test case nowiki}} can do without them. But in the interests of... I don't know, consistency, harmony, whatever, it seems like bridge.nowiki could include this logic:

	local options = {}
	for k, v in pairs(args) do
		local underscoreOptionKey = type(k) == 'string' and k:match('^_(.*)$')
		if underscoreOptionKey then
			options[underscoreOptionKey] = v
		else
			options[k] = v
		end
	end
	local code = options.code or options[1]
	local invocationObj = NowikiInvocation.new(code, cfg)
	options.code = nil
	options[1] = nil
	-- Assume we want to see the code as we already passed it in.
	options.showcode = options.showcode or true
	local testCaseObj = TestCase.new(invocationObj, options, cfg)

...So that e.g. |_collapsible= and |collapsible= are equivalent, meaning the user has the option to pass the exact same arguments as all the other templates in the group. FeRDNYC (talk) 18:44, 15 July 2023 (UTC)

Thats fair, I've gone ahead and implemented that here. Either option should work now. Aidan9382 _(talk) 19:04, 15 July 2023 (UTC)

This change appears to have caused, or may have caused, an error in some test cases. The one that came to my attention is {{Circular reporting/testcases}}, where some "span title" code is being exposed. My wild guess is that a rendered equals sign in _title may be causing the problem. – Jonesey95 (talk) 21:15, 16 July 2023 (UTC)

This change right here shouldn't of (and hasn't) caused the issue, since this only effects how args are processed in {{Test case nowiki}}, and the normal {{Test case}}'s behaviour is unchanged. I suspect that specific test case has been broken for a while. I've fixed it here and here, and it should now work fine. Aidan9382 _(talk) 06:04, 17 July 2023 (UTC)

Strange. I wonder why that page popped into the error report right after the change, and why this Module shows in Related changes for the testcases page. It is also odd that this module appears in "Pages transcluded onto the current version of this page" when you edit the testcases page. Maybe it's a coincidence. P.S. I have modified both of the changes, since one of them caused Linter errors in other places. – Jonesey95 (talk) 12:52, 17 July 2023 (UTC)

It is also odd that this module appears in "Pages transcluded onto the current version of this page" when you edit the testcases page - that part makes sense, since {{Test case}} uses this module, as does {{Test case nowiki}} and a couple of the other related templates. As for why it took editing this for it to appear in an error report, even I'm not sure on that one. It definitely didn't change the behaviour, so maybe this change just caused it to purge and appear in the report. Could the report have had a recent change on what it picks up? Aidan9382 _(talk) 13:00, 17 July 2023 (UTC)

Many, many thanks, Aidan9382, for putting this in place. FeRDNYC (talk) 14:52, 20 July 2023 (UTC)

Extended-confirmed-protected edit request on 17 October 2023

Please, remove the n of the word templaten in the line number 29. Nishimoto, Gilberto Kiyoshi (talk) 16:38, 17 October 2023 (UTC)

 Done Aidan9382 _(talk) 16:42, 17 October 2023 (UTC)

Trim input's newlines?

Many people use {{test case nowiki}} as follows for aesthetics:

{{test case nowiki|<nowiki>
{{wrapper template top}}
{{__TEMPLATENAME}}
{{wrapper template bottom}}
</nowiki>}}

This causes an extra newline to be inserted before and after the template's part inside the test case frame. It would be wonderful if this module would trim the input's newlines. Aaron Liu (talk) 15:52, 8 August 2024 (UTC)

Do you mean to trim newlines in a way that would make

{{test case nowiki|<nowiki>
{{wrapper template top}}
{{__TEMPLATENAME}}
{{wrapper template bottom}}
</nowiki>}}

equivalent to

{{test case nowiki|<nowiki>{{wrapper template top}}
{{__TEMPLATENAME}}
{{wrapper template bottom}}</nowiki>}}

? That is, trim newlines which are right next to the outer pair of <nowiki>...</nowiki> tags. —⁠andrybak (talk) 22:47, 8 August 2024 (UTC)

Yes, thanks. Aaron Liu (talk) 23:28, 8 August 2024 (UTC)

Having multiple __TEMPLATENAME__s

I wanted to gauge interest in possibly extending the Module code to (optionally) support testing nowiki'd code that contains multiple template name substitutions. The primary use case would be testing templates that are only useful in concert with others, like (for example) {{archive top}}.

It's certainly possible to test that template in isolation, using a {{Test case nowiki}} transclusion at Template:Archive top/testcases like:

{{Test case nowiki|<nowiki>
{{__TEMPLATENAME__}}
{{Lorem ipsum}}
{{archive bottom}}
</nowiki>}}

...That'll get you a perfectly good test of {{archive top}} vs. {{archive top/sandbox}}.

But it might be useful, at times, to pair the tested {{archive top}} with a corresponding {{archive bottom}}, for when changes being made in tandem are being tested.

To meet those needs, the Module might need to support something like the following:

{{Test case nowiki|template1name1=archive top|template1name2=archive bottom|<nowiki>
{{__TEMPLATENAME1__}}
{{Lorem ipsum}}
{{__TEMPLATENAME2__}}
</nowiki>}}

This would, my thinking goes, permit testing the combination of {{archive top}} and {{archive bottom}} against the combination of {{archive top/sandbox}} and {{archive bottom/sandbox}} (unless different templates were specified for |template2name1= and |template2name2=).

As with the citation templates' handling of |author=, |first=, |last=, etc.:

1. |template1= would effectively become an alias for |template1name1= (with the same default of {{#titleparts: {{PAGENAME}}| -1}})
2. Same for |template2= and |template2name1= (again having the same default of {{{template1name1}}}/sandbox)
3. |template3= == |template3name1=, etc.
4. __TEMPLATENAME__ would be interchangeable with __TEMPLATENAME1__.

Using only |template1name1=, |template2name1=, and __TEMPLATENAME1__ would therefore be equivalent to the current syntax, as would using only __TEMPLATENAME1__ and leaving the template-selection parameters at their default values.

...Potentially useful? Some flaw I've overlooked in the proposed functionality? Or just not worth the effort, regardless whether or not it would work? FeRDNYC (talk) 18:21, 29 August 2024 (UTC)

I've since decided that the parameter names |template1name1= and |template1name2= feel awkward and confusing. They should be |template1name1= and |template2name1=, if anything, but that won't work because |template1= and |template2= are existing parameters that have different, incompatible definitions in the code.

Nevertheless, a call using e.g. |template1name1=archive top|template1name2=archive bottom just feels confusing. (They're not different names for the first template, they're different templates to be used in the first rendering of the test case.)

So to avoid that confusion, I think it would be better to make |templatename1= the new equivalent for |template1=, instead. The second template to use in rendering the test case would be just |templatename2=. |template2name1= would still be equivalent to |template2=, and |template2name2= would still be the corresponding equivalent to |templatename2= for the second rendering of the case. (Though often they'd not be specified, and default to the /sandbox versions of the templates specified for |templatename1= .. |templatenameN=. The notion of a "{{{template1}}}" parameter would be a deprecated compatibility labeling — the "proper"/"preferred" identifiers would be {{{templatename1}}} ... {{{templatenameN}}}. Which, handily, would also exactly correspond to the placeholder strings __TEMPLATENAME1__ ... __TEMPLATENAMEN__ used to insert them into the nowiki'd code.

The other option would be |case1template1= ... |case1templateN= for the first rendering, then |case2template1= ... |case2templateN= for the normally-defaulted-to-/sandbox versions, and so on... But that's a much bigger and more disruptive change that doesn't feel worth the upheaval. (It also changes the meaning of "template1" vs. "template2", compared to their current definition. So, still potentially confusing.) FeRDNYC (talk) 03:47, 7 October 2024 (UTC)

Why visual matches instead of string matches?

Sorry for what must be a silly question, but why does this tool require visual comparison rather than doing a match and emitting TEST FAIL! Johnjbarton (talk) 22:19, 6 October 2024 (UTC)

Not sure I follow — a string comparison of the output is precisely what the module's TestCase:templateOutputIsEqual() function does; the {{Collapsible test case}} template — or any of the templates, with |_collapsible=yes set — will even automatically collapse any testcase where the results are the same. (As well as coloring the top bar of the collapsible box green (same output) vs. yellow (differences detected).)

However, it's often the case that differences between the main version of a template and its sandbox version are intentional. (They'll be present whenever development is being done on the sandbox version of the code, for example.) So, characterizing differences as "TEST FAIL!" isn't strictly accurate, as having the same output isn't "success" and having different output isn't "failure". The point, when there are differences, is to demonstrate/examine how/whether the sandbox version has improved the output, vs. the live code. (If so, then a request can be made to transfer the sandbox code to the live template. At which point, the differences go away.) FeRDNYC (talk) 23:38, 6 October 2024 (UTC)

(Template test cases are therefore not like traditional programming unit tests, where the result of some code is compared to a known expected value, and any deviation represents a failure to perform as expected. Template test cases compare and contrast two versions of the same template, and any differences in output are interesting as a means of evaluating the code changes that created those differences.) FeRDNYC (talk) 23:51, 6 October 2024 (UTC)

Thanks! Sorry, I only read up to the Collapsible test cases and stopped, because I was far from wanting to collapse test cases. I did not see that how fails are alerted. Johnjbarton (talk) 00:01, 7 October 2024 (UTC)

Empty testcases

Maybe could someone give a hint why when using this template on local wiki it is not showing comparison tables as in enwiki? I have migrated same modules and code, but it is not showing anything, just some text: lt:Template:Infolentelė/testcases Zygimantus (talk) 21:02, 13 October 2024 (UTC)

Click on the triangle next to "Straipsnyje naudojami šablonai:" to see the templates that are being requested. You may need to create one or more of the red templates in order to make that page work. – Jonesey95 (talk) 00:36, 15 October 2024 (UTC)

Yes, I thought about that, I have another page: lt:Šablonas:Sąrašas be punktų/testcases for that, this one is minimal and does not have redlinks, still no comparison is visible, maybe some kind of unknown gadget or plugin is used? Zygimantus (talk) 11:00, 15 October 2024 (UTC)

I am stuck then. Maybe something in one of the modules or templates is dependent on an English-language name of a page or namespace, but that is a guess. – Jonesey95 (talk) 12:52, 17 October 2024 (UTC)

Will try something, it is a pity that no error message or something is visible, maybe then it is related to CSS styles... Zygimantus (talk) 21:15, 18 October 2024 (UTC)

@Zygimantus For starters I think you need to configure http://lt.wiki.x.io/wiki/Module:Template_test_case/config for the wiki — in particular, the wrappers table, which the module uses to map names of templates to the functions and arguments they should use.

If you notice, all of the templates related to Module:Template test case all contain the same code:

{{#invoke:Template test case|main}}

That's because, when the module sees it's being invoked from e.g. Template:Testcase table, the wrappers table tells it to automatically add _format = 'columns' to the arguments. But on your wiki the module will never be invoked from Template:Testcase table, it'll be invoked from Šablonas:Testcase table, and there's no wrapper mapping for that template page name. That's, at the very least, why your test cases are being formatted as rows instead of columns.

It may not be the whole issue, but it's definitely an issue.

You're also missing Module:Suppress categories, which the your Šablonas:Suppress categories depends on. (Discovered by editing the testcases page, then selecting "Templates used" in the hamburger menu and looking for redlinks in the resulting list — a handy way to root out broken dependencies. There are a few others.) FeRDNYC (talk) 06:09, 25 October 2024 (UTC)

@FeRDNYC: thanks. I had to translate „Template“ text in that config page. Also I wasn't aware that on local wikis these pages are not the same: lt:Šablonas:Testcase table and lt:Template:Testcase table. For example, if you click on those links, they will direct to same page, but on Module page it works not like that I suppose. Zygimantus (talk) 13:06, 25 October 2024 (UTC)

@Zygimantus Yeah, the problem is that lt:Template:Testcase table acts as an alias for the canonical name — which works fine, going in, because you end up at the same place. But it doesn't work in reverse, so when the module asks "What template am I being called from?", the answer will never be "Template:Testcase table"; that's not what the page is called. FeRDNYC (talk) 16:37, 25 October 2024 (UTC)