Comments

Status: Needs review » Needs work

The last submitted patch failed testing.

sun’s picture

Status: Needs work » Needs review
StatusFileSize
new4.9 KB
dries’s picture

+++ includes/locale.inc	6 Dec 2009 07:51:37 -0000
@@ -242,6 +242,7 @@ function locale_languages_edit_form($for
+    drupal_exit();

Are you sure you want to call drupal_exit() and not 'return'? I'd have to dig a bit deeper but it could affect some callbacks not being called.

+++ includes/locale.inc	6 Dec 2009 07:51:37 -0000
@@ -1695,7 +1697,7 @@ function _locale_import_po($file, $langc
-    watchdog('locale', $skip_message, NULL, WATCHDOG_WARNING);
+    watchdog('locale', '%file: Disallowed HTML in @count string(s)', array('%file' => $file->filename, '@count' => $skips), WATCHDOG_WARNING);
   }

It might be slightly better to move %file to appear later in the string. We only see x characters on the watchdog overview page and I'm worried that we'd see the filename only. We should lead with the part of the message that provides context.

sun’s picture

1) http://api.drupal.org/api/function/drupal_exit/7 and http://api.drupal.org/api/function/drupal_page_footer/7 are almost identical, except that drupal_page_footer() additionally tries to serve from cache as well as to update a couple of shutdown caches. Both not required for 403 and 404 pages. Actually, we now use drupal_exit() everywhere in Drupal in such situations.

2) Doable.

sun’s picture

StatusFileSize
new4.9 KB

Fixed 2).

dries’s picture

Status: Needs review » Fixed

Committed to CVS HEAD. Thanks!

sun’s picture

Status: Fixed » Needs work

Hm, the actual output of that watchdog message is:

http://qa.drupal.org/pifr/test/21800

locale: 2 disallowed HTML string(s) in temporary://po_KVt7wr.

But I don't think the original $file is passed... So we either make it pass the original file or we drop the filename (but then the entire watchdog message wouldn't make much sense)

sun’s picture

Status: Needs work » Needs review
StatusFileSize
new12.05 KB

There some more easily fixable failures. Not yet sure what to do about aforementioned watchdog(), but we can continue to fix the other fails in the meantime.

That said, something is horribly wrong with PIFR's error logging. The same drupal_cache_system_paths() function in path.inc that we already touched in the last patch now threw another PHP warning that wasn't contained before. :-/

Fixes some senseless assertions in Locale tests.

But we also have some watchdog errors (403) in the new HTTPS functionality test. Problem: I don't understand this test, so I can only fix the obvious.

Status: Needs review » Needs work

The last submitted patch failed testing.

sun’s picture

Status: Needs work » Needs review
StatusFileSize
new12.05 KB

errr. Fixing that false-fixed-failing-test. ;)

webchick’s picture

Status: Needs review » Active

I reviewed #10 with sun in IRC:

I asked about:

+    $this->drupalPost(NULL, $edit, t('Save configuration'));

This means "post back to the current page." I'm sure if I had the drupalPost docs in front of me rather than reading a patch file, I would know that. ;)

I was also concerned about how often this patch adds lines like this:

+    $this->assertResponse(404);
...
+    $this->assertNoResponse(404);

...and how to explain to test authors when they need to do so.

sun explained that you do these explicitly when your test depends on a 404/403 response; for example, while testing that the search block appears on the 404 page.

Committed #10 to HEAD, marking back to active.

carlos8f’s picture

Er, am I going crazy or does this assertNoResponse() method not exist in simpletest? All the tests that use this method fail with:

Fatal error: Call to undefined method PathTestCase::assertNoResponse() in httpdocs/modules/path/path.test on line 67

Isn't the method supposed to be in drupal_web_test_case.php? http://drupalcode.org/viewvc/drupal/drupal/modules/simpletest/drupal_web...

sun’s picture

Status: Active » Needs review
StatusFileSize
new3.57 KB

errrr - WTF? Either that existed previously, or this API is totally inconsistent.

Thanks! Let's fix the fatals first. :-/

man... we absolutely need to get #653940: Clean-up: Tests do not report all errors done. This is insane. I can introduce fatal errors, warnings, and notices, and absolutely nothing tells me. Totally insane.

I'd even consider to commit #653940: Clean-up: Tests do not report all errors _now_. ALL patches in the queue and all developers and all maintainers are relying on a testing system that does not report errors. That's unacceptable.

carlos8f’s picture

agreed! that was really weird. glad i wasn't crazy.

carlos8f’s picture

Status: Needs review » Reviewed & tested by the community

#13 fixes the fatals in HEAD, let's get it committed then set back to active.

catch’s picture

Title: Various failures everywhere :) » Fatal errors in tests
Issue tags: +Quick fix

Yep. Slightly more quick-commit friendly issue-title too ;)

dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to CVS HEAD. Thanks.

catch’s picture

Title: Fatal errors in tests » Failures everywhere
Status: Fixed » Needs work
Issue tags: -Quick fix

Back to the remainder of #10.

catch’s picture

Priority: Normal » Critical

Anything but normal.

sun’s picture

Title: Failures everywhere » Various failures everywhere :)
Status: Needs work » Active

Note that I deferred the work on #652394: Aggressive watchdog message assertion and prioritized #653940: Clean-up: Tests do not report all errors, because there are a couple of watchdog messages in the former test results that I cannot really explain. In the latter, I was able to reveal

3 fail(s), and 13,051 exception(es)

in the current code and already brought that down to

0 fail(s), and 123 exception(es)

However, I need some OOP help though, because most of the remaining exceptions are caused by wrong testing class method invocations.

c960657’s picture

Status: Active » Reviewed & tested by the community

It looks like #13 wasn't committed. Instead the patch for #459786: countQuery() should also remove all_fields statements was committed twice by mistake. The last commit message had a reference to this issue.

dave reid’s picture

Confirmed this absolutely broke core testing.

carlos8f’s picture

Title: Various failures everywhere :) » [TESTING BROKEN] Fatal errors in tests
Issue tags: +Quick fix

Confirmed #21 that #13 wasn't committed. Changing the title back with some emphasis.

dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to CVS HEAD. For real now. The network at DIDW is really unreliable so sometimes things hang for minutes.

carlos8f’s picture

Title: [TESTING BROKEN] Fatal errors in tests » Fix errors uncovered using aggressive watchdog assertion
Status: Fixed » Active
Issue tags: -Quick fix

Changing title to something a little more descriptive :D

sun’s picture

Status: Active » Fixed

I think that, for now, no hidden errors are remaining from that other patch.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.