git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [WIP/PATCH v3] gitweb: add test suite with Test::WWW::Mechanize::CGI

From
Jakub Narebski <jnareb@gmail.com>
Date
Jun 20, 2008, 18:03 UTC
Message-ID
<200806202003.55919.jnareb@gmail.com>
In-Reply-To
<485BB578.3040605@gmail.com>
On Fri, 20 Jun 2008, Lea Wiemann wrote:
Show 7 quoted lines
> Jakub Narebski wrote:
>>
>> Second, I think it would be better if adding XML checks (RSS, Atom,
>> OPML) would be left as separate commit.
> 
> Sure; FWIW I'm generally in favor of having a large initial commit for 
> new independent files [...]

I just think that having this separate could help bisectability in the case of errors.

Show 9 quoted lines
>>> +# set up test repository
>> 
>> I have created this part as a copy of older t9500 gitweb test, thinking
>> about what we might want to test, but the WIP of Mechanize based t9503
>> doesn't have yet tests for those specific features.
> 
> I was thinking about that.  Right now the tests are so generic that you 
> can replace the test repository with anything else as long as it has 
> some commits (and later some tags, etc.).  That's kinda nice.

Well, I've tried to put the cases where something can go wrong, and to cover wide range of possibilities. Rename, copy, typechange, merge commit for testing *diff views, symlink to test 'tree' view, different types of tags and tagged objects...

What could be added is different types of stage output: filenames with
'*', '+', '=', ':', '?', whitespace, etc.  Checking if submodules
doesn't trip gitweb would be good idea too.
 
> I'm generally not in favor of maintaining any test count plans; they're 
> an unnecessary failure source, and I don't think they buy us much, if 
> anything -- correct me if I'm missing something Perl-specific here.
While they can detect otherwise unnoticed errors, I think most of time
they are error in test counting... so I can agree with that.
 
Show 6 quoted lines
>> Why do you use shortened SHA1 identifier, instead of full SHA1?
>> Links in gitweb use full SHA1.
> 
> That's for readability in the test output; links get checked anyway, 
> don't they?  If you think we should be testing against full SHA1s, 
> that's fine too.
This would reduce number of operations when crawling gitweb output.
 
[about workaround bug in TWM::CGI when path to application contains
 embedded space].
> ISTR that using cgi(sub ...) gives us problems with untrappable exits in 
> gitweb.cgi (and possibly more things), right?

Actually ->cgi_application(<path>) is implemented using ->cgi(<sub>) in TWM::CGI. The bug is that it uses straight "system($application)", without any quoting, after ensuring that $application is absolute path (so quoting it beforehand won't work).

> I'm fine with the workarounds we have in place, they don't seem brittle.

They work around the fact that we use 'trash directory', but they would fail if you run test from the directory which contains spaces, for example "/home/Lea Wiemann/git/t" (I think this has greater probability happening on operating systems other than Linux, for example MS Windows with "My Documents" or "Program Files").

Show 6 quoted lines
>>> +our $baseurl = "http://localhost";
>>> +our($params, $url, $pagedesc, $status);
>> 
>> I think we can use 'my' here;
> 
> They're used in subroutines, so I believe 'our' is correct here.
Actually 'my' would work here too; the problem with gitweb being
forced to use 'our' to make it work with mod_perl isn't about the
fact that they are global variables, but with initializing them,
as mod_perl wraps whole gitweb in a block (processing requests).
 
Show 7 quoted lines
>> As to the rest of the test: I think as preliminary test it is a good
>> thing to have.  We can think about what tests to add later (unless you
>> rather have exhaustive test suite now...).
> 
> I'll be writing tests as I go and change parts of gitweb.  I won't be 
> able to write exhaustive tests, but I at least want to make sure that 
> the code I'm changing is covered somehow.

Write test when we notice something breaking seems a common theme in git development... ;-)

-- 
Jakub Narebski
Poland
Previous: Lea WiemannNext: Lea Wiemann
Message 19 of 41 in “gitweb: Use Test::WWW::Mechanize::CGI to test gitweb output”
  1. gitweb: Use Test::WWW::Mechanize::CGI to test gitweb outputJakub Narebski, Jun 14, 2008
  2. Lea WiemannJun 14, 2008
  3. Jakub NarebskiJun 14, 2008
  4. Lea WiemannJun 14, 2008
  5. Jakub NarebskiJun 14, 2008
  6. Lea WiemannJun 14, 2008
  7. Jakub NarebskiJun 15, 2008
  8. Lea WiemannJun 14, 2008
  9. Jakub NarebskiJun 14, 2008
  10. gitweb: add test suite with Test::WWW::Mechanize::CGILea Wiemann, Jun 14, 2008
  11. Jakub NarebskiJun 15, 2008
  12. Lea WiemannJun 15, 2008
  13. Jakub NarebskiJun 16, 2008
  14. Lea WiemannJun 16, 2008
  15. Jakub NarebskiJun 16, 2008
  16. gitweb: add test suite with Test::WWW::Mechanize::CGILea Wiemann, Jun 20, 2008
  17. Jakub NarebskiJun 20, 2008
  18. Lea WiemannJun 20, 2008
  19. Jakub NarebskiJun 20, 2008
  20. Lea WiemannJun 20, 2008
  21. gitweb: add test suite with Test::WWW::Mechanize::CGILea Wiemann, Jun 20, 2008
  22. gitweb: add test suite with Test::WWW::Mechanize::CGILea Wiemann, Jun 23, 2008
  23. gitweb: add test suite with Test::WWW::Mechanize::CGILea Wiemann, Jun 23, 2008
  24. Junio C HamanoJun 23, 2008
  25. Lea WiemannJun 23, 2008
  26. Jakub NarebskiJun 23, 2008
  27. Lea WiemannJun 23, 2008
  28. Jakub NarebskiJun 23, 2008
  29. Lea WiemannJun 24, 2008
  30. gitweb: add test suite with Test::WWW::Mechanize::CGILea Wiemann, Jun 24, 2008
  31. gitweb: add test suite with Test::WWW::Mechanize::CGILea Wiemann, Jun 26, 2008
  32. gitweb: add test suite with Test::WWW::Mechanize::CGILea Wiemann, Jun 26, 2008
  33. Jakub NarebskiJun 29, 2008
  34. Lea WiemannJun 29, 2008
  35. Jakub NarebskiJun 29, 2008
  36. Lea WiemannJun 30, 2008
  37. Jakub NarebskiJun 30, 2008
  38. Junio C HamanoJun 24, 2008
  39. Lea WiemannJun 24, 2008
  40. Jakub NarebskiJun 24, 2008
  41. Jakub NarebskiJun 30, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.