From, http://drupal.org/node/1705748#comment-6422184:

Actually, before we jump too fast. Based on your comment http://drupal.org/node/1717868#comment-6422150 I looked into the --verbose flag which I remember existing, but not to replace the simpletest_verbose variable.

--verbose Output detailed assertion messages in addition to summary.
Which is intended to spit out the individual row-by-row messages (assertions) in the output of the run-tests.sh script. Which is quite different from the simpletest_verbose variable which was to control the verbose page capturing functionality in DrupalWebTestCase.

We probably want to split these out and rename one. May also want to default to false on the command line? dunno.

I think --verbose flag as it stand now works the way that is most consistent with other scripts and makes sense. Perhaps we rename simpletest_verbose variable to 'capture' or something along those lines to 'capture browser shot' etc. I don't like those names just providing a thought basis.

If we default cli to false then using the cli then might do.

--print-details --verbose

--print-details to print out assertion messages
--print-results
--results
--details
,etc

Once committed http://drupal.org/node/1719530#comment-6427162 should be reverted.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sun’s picture

Issue tags: +Testing system

I actually don't quite understand the differentiation you're trying to make -- can you clarify a bit more?

Are you thinking of a --verbose-browser option?

boombatower’s picture

Yea, --verbose-browser is a good name. I was having a hard time coming up with a good name for the flag.

The difference being that simpletest_verbose (--verbose-browser) controls the internal browser collecting, saving, and outputting links to the page output from each request. Whereas --verbose simply prints the messages that are already being collected...it just is "more verbose" in it's output to the user.

They seem to do fairly different things (although, --verbose-browsers should require --verbose) and only one has a performance hit it seems like they should be separate flags, but if so then --verbose-browser should probably automatically enable --verbose flag for simplicity and ease-of-use.

sun’s picture

Title: Create run-tests.sh flag for simpletest_verbose variable or merge with --verbose » Split Simpletest --verbose into --verbose-browser
boombatower’s picture

Title: Split Simpletest --verbose into --verbose-browser » Add Simpletest --verbose-browser flag

There seems to be a misunderstanding as there is currently _NO_ way to trigger browser verbosity through a flag...which was my point in the other issue and why the testbot cannot control this given our new approach

boombatower’s picture

Title: Add Simpletest --verbose-browser flag » Split Simpletest --verbose-browser flag

After some confusion summarized http://drupal.org/node/1705748#comment-6435582

The documentation needs to be fixed, which we can do when we split the flag or just fix docs if we choose not to.

  --verbose   Output detailed assertion messages in addition to summary.

Before http://drupal.org/node/1719530#comment-6326150 (adding --keep-results flag issue) that was correct. After adding it now also triggers the collection of browser requests (something that is/was a separate feature not controlled by the flag before).

The change did not simply allow a variable to be overridden using the flag it added meaning to the flag which never controlled the functionality of the variable before. These should probably have been split out into separate issues so things didn't get so confused.

boombatower’s picture

Title: Split Simpletest --verbose-browser flag » Correct mistake introduced in simpletest cmi conversion by introducing --verbose-browser flag
Assigned: Unassigned » boombatower
Category: task » bug
Status: Active » Needs review
FileSize
1.54 KB

I have not tested this.

sun’s picture

Looks good to me.

I think we also want to update simpletest.module's config setting key from 'verbose' to 'verbose_browser'.

boombatower’s picture

sounds like a reasonable addition

boombatower’s picture

How about adding --print-assertions which is probably better since $verbose can be used for other things and seems more accurate since we simply print assertions which isn't really a normal definition of verbose.

sun’s picture

Ugh, no please not. --verbose is clear. Let's get back to the previous patch, do the adjustment in #7, and be done with it.

boombatower’s picture

hmm, I mean not like we call the assertions in web interface verbose. Seems like we would need to change the assertions with link text of verbose and the directory to verbose_browser...etc to be consistent, vs verbose being used to be literally verbose things such as browser dumps and something else to print assertions.

Seems like if we want to correctly fix and still use two verbose flags we need to make a lot of other changes some of which don't make a whole lot of sense which is what led me to change directions.

alexpott’s picture

Issue summary: View changes
FileSize
4.4 KB

The patch attached implements --verbose-browser flag and allows the run-tests.sh to override whatever is set in the simpletest.settings using this flag. The --verbose flag in run-tests.sh is only for printing the results of test assertions.

ianthomas_uk’s picture

"verbose browser" to me sounds like a tool to browse verbose output.
"capture browser" makes more sense to me, or perhaps "capture HTML" (not that it will always be HTML).

jhedstrom’s picture

Status: Needs review » Needs work
Issue tags: +Needs reroll
gaurav_varshney’s picture

Status: Needs work » Needs review
FileSize
4.29 KB

Updated patch for drupal 8.0.0-beta4

pwieck’s picture

Issue tags: -Needs reroll

mgifford queued 15: 1774002.14.patch for re-testing.

Status: Needs review » Needs work

The last submitted patch, 15: 1774002.14.patch, failed testing.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

quietone’s picture

Project: Drupal core » SimpleTest
Version: 8.9.x-dev » 8.x-3.x-dev
Component: simpletest.module » Code

Triaging issues in simpletest.module as part of the Bug Smash Initiative to determine if they should be in the Simpletest Project or core.

This looks like it belongs in the Simpletest project.