Bug #79632 for Template-Plugin-Latex: Test t/13-latex_encode.t fails with new version of LaTeX::Encode (0.06)

Thu Sep 13 16:42:32 2012 LANGMIC [...] cpan.org - Ticket created

Subject:

Test t/13-latex_encode.t fails with new version of LaTeX::Encode (0.06)

... MATCH FAILED input: [[% USE Latex; "\\LaTeX" | latex_encode; %]\n] expect: [\textbackslash LaTeX] output: [{\textbackslash}LaTeX] not ok 15 - template text 6 did not match expected ... MATCH FAILED input: [[% USE Latex; "\\&#_^{}\\&#_^{}" | latex_encode; %]\n] expect: [\textbackslash\&\#\_\^{ }\{\}\textbackslash\&\#\_\^{ }\{\}] output: [{\textbackslash}\&\#\_\^{ }\{\}{\textbackslash}\&\#\_\^{ }\{\}] not ok 21 - template text 9 did not match expected ... It seems the newest version of LaTeX::Encode surrounds named characters with curly brackets which is not expected by this test.

Wed Dec 05 07:51:15 2012 jquelin [...] cpan.org - Cc JQUELIN added

Sun Mar 24 12:40:54 2013 lucs [...] cpan.org - Correspondence added

diff -U3 13-latex-encode.t 13-latex-encode.t.new --- 13-latex-encode.t 2009-03-11 13:37:47.000000000 -0400 +++ 13-latex-encode.t.new 2013-03-24 12:13:34.000000000 -0400 @@ -69,7 +69,7 @@ -- test -- [% USE Latex; "\\LaTeX" | latex_encode; %] -- expect -- -\textbackslash LaTeX +{\textbackslash}LaTeX # Latex_Encodeify string with a "#" -- test -- @@ -87,7 +87,7 @@ -- test -- [% USE Latex; "\\&#_^{}\\&#_^{}" | latex_encode; %] -- expect -- -\textbackslash\&\#\_\^{ }\{\}\textbackslash\&\#\_\^{ }\{\} +{\textbackslash}\&\#\_\^{ }\{\}{\textbackslash}\&\#\_\^{ }\{\} # Latex_Encodeify string with intelligent double quotes -- test --

Sun Mar 24 12:40:55 2013 The RT System itself - Status changed from 'new' to 'open'

Sat Jun 22 09:52:07 2013 gregoa [...] cpan.org - Cc GREGOA added

Wed Feb 19 05:33:40 2014 chris.travers [...] gmail.com - Correspondence added

To my mind the best option here is to verify that this is being tested in LaTeX::Encode and then drop the failing test cases. It's one thing to test that LaTeX::Encode is properly integrated. It's something else to worry about the specifics by which LaTeX::Encode handles this from a module that may run with various versions of LaTeX::Encode installed. Tests should test the contract pieces that an individual module is responsible for, not the underlying behavior of dependencies.

Wed Feb 26 00:51:02 2014 chris.travers [...] gmail.com - Correspondence added

On Wed Feb 19 05:33:40 2014, EINHVERFR wrote: Show quoted text

> To my mind the best option here is to verify that this is being tested > in LaTeX::Encode and then drop the failing test cases. It's one thing > to test that LaTeX::Encode is properly integrated. It's something > else to worry about the specifics by which LaTeX::Encode handles this > from a module that may run with various versions of LaTeX::Encode > installed. Tests should test the contract pieces that an individual > module is responsible for, not the underlying behavior of > dependencies.

I have pushed out 3.03. It complains about missing permissions on the index but as a co-maintainer it should be available soon. The approach I took was what was described here. The LaTeX::Encode tests for Template::Plugin::Latex have been stripped down to the most important ones and largely serve the purpose now of making sure that LaTeX::Encode is being properly called. I will be closing this one shortly as soon as 3.03 becomes the default. 3.02.01 should fix it too but there is a packaging problem with the version number there.

Wed Feb 26 00:51:03 2014 chris.travers [...] gmail.com - Taken

Wed Feb 26 00:51:04 2014 chris.travers [...] gmail.com - Fixed in 3.02.01 added

Thu Feb 27 22:50:44 2014 chris.travers [...] gmail.com - Status changed from 'open' to 'resolved'

Thu Feb 27 22:50:44 2014 chris.travers [...] gmail.com - Fixed in 3.03 added