| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
It wasn't clear that system tests don't run with the rest of the test
suite and are part of a separate command.
This documents the `test:system` command as well as update the Rails
runner help documentation to make it clearer that system tests are run
via their own command by default.
|
| |
|
|
|
|
|
| |
Argument was added to `aggregated_results` in minitest 5.10.2.
Ref: https://github.com/seattlerb/minitest/commit/c6ba2afd90473b76d289562edd24f7d7ca8484f9
|
|
|
|
|
|
|
|
|
|
| |
These tests may be expansive so let's only allow users to run them
through `bin/rails test:system` or by passing a path to the `test`
command.
The same applies for `bin/rake test`.
Refs #28109.
|
|
|
|
|
|
|
|
|
| |
```
Minitest.run_via[:rails] = true
```
👆 would break because a simple alias won't catch the second
true argument there.
|
|\
| |
| | |
WIP: Capybara Integration with Rails (AKA System Tests)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Originally I had set up system testing to have one configuration option
to be set in the test environment. After thinking it over I think a
generated class on app creation would be best. The reason for this is
Capybara has a ton of configuration options that I'm sure some folks
want to use.
Thinking about how we handle screenshots, database transactions, and a
whole bunch of other settings it would be better for users to be able to
turn all of that on and off.
When an app or scaffold is generated a `test/system_test_helper.rb` test
helper will be generated as well. This will contain the class for tests
to inherit from `ActionSystemTestCase` which will inherit from
`ActionSystemTest::Base`. Here is where users can change the test
driver, remove the screenshot helper, and add their additional Capybara
configuration.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
By moving to the TestUnit Railtie, and doing the file requirement
inside the onload call we can avoid loading ActionSystemTest in
production and load it in the test env.
This is important for performance reasons - loading up unnecessary files
and object is expensive, especially when they should never be used in
production.
|
| |
| |
| |
| |
| |
| |
| | |
* Generates system test requirements with new Rails app
* Includes required default gems in Gemfile for Rails app
* Generates a single system test case
* Generates a system test case with scaffold
|
|/
|
|
|
| |
When executing the test via rake, since `rake` is set for `run_via`, `ruby` should not be set.
Related 2cb6c27310452da11b93d729c3b760ce988106e1
|
|
|
|
|
|
|
| |
Replaces the rake_patterns instance variable with simple require, as
`autorun` will run tests from all eagerly required test files.
Fixes #27801
|
| |
|
|
|
|
| |
We need to use on_load so that plugins will get the same functionality
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test framework should not be autoloaded in production mode. Before
this commit, the testing railtie would extend AS::TestCase. This caused
AS::TestCase to be preloaded regardless of the environment in which we
were running.
This commit just moves the code that adds line filtering support in to
the test command where we actually execute the test runner. That allows
us to maintain the line runner feature but only load the minimal amount
of code we need.
|
|
|
|
|
|
|
| |
Makes sure we get support for `Minitest.after_run` hooks and don't
accidentally run tests twice.
Requires overriding minitest `run` to respect the TESTOPTS variable.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Rails test runner supports three ways to run tests: directly, via rake, or ruby.
When Running with Ruby ala `ruby -Itest test/models/post_test.rb` our test file would
be evaluated first, requiring `test_helper` and then `active_support/testing/autorun`
that would then require the test file (which it hadn't been before) thus reevaluating
it. This caused exceptions if using Active Support's declarative syntax.
Fix this by shifting around when we set the how we're run to closer mimick the require
order.
If we're running with `bin/rails test` the test command file is run first and we then
set `run_with_rails_extension`, later we hit `active_support/testing/autorun` and do
nothing — because we've been run elsewhere.
If we at this point haven't set `run_with_rails_extension` we've been running with
`ruby` this whole time and thus we set that.
We should always trigger `Minitest.autorun` as it doesn't hurt to call it twice.
Consolidate the two methods into a single one that better brings out the intent of
why they're there.
|
|
|
|
|
|
|
|
|
| |
A few have been left for aesthetic reasons, but have made a pass
and removed most of them.
Note that if the method `foo` returns an array, `foo << 1`
is a regular push, nothing to do with assignments, so
no self required.
|
|
|
|
| |
Some case expressions remain, need to think about those ones.
|
| |
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
|
|
| |
If run the test over the `rake` command, because of the test patterns is passed
via `rake_run` method, do not need to be obtained from the argv.
This probably fixes #24372.
|
|
|
|
|
| |
Didn't feel we were clear enough about our motivation for placing Rails first
and why we needed to call `load_plugins`.
|
|
|
|
| |
The useless explicit self calls were driving me nuts.
|
|
|
|
|
|
|
|
|
|
|
| |
When calling `load_plugins` minitest would fill out its extensions, then
we'd tackle ourselves on as the last plugin. Because minitest loads plugins
in order we will ultimately have the last say on what reporters will be used.
Invert that strategy by putting ourselves first and give other plugins plenty
of leeway to override our default reporter setup.
Fixes #24179.
|
|
|
|
|
| |
We should be able to pass options to minitest via TESTOPTS environment
variable
|
|
|
|
| |
Get it? ( ͡° ͜ʖ ͡°)
|
|
|
|
|
|
|
| |
The process of converting `Test` to `String` is already defined in minitest.
I think it is better to use that for the consistency of output content.
ref: https://github.com/seattlerb/minitest/blob/master/lib/minitest/test.rb#L261..L267
|
| |
|
|
|
|
|
| |
This is a follow-up to ea70c29 to bring back the assertion error
location information provided by minitest.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 0db310586ac3e15be95d2ef27ff40cfa24c05c10.
Closes #23686.
Conflicts:
railties/test/application/test_runner_test.rb
It's possible that the `result.location` returned by minitest is outside
the test file itself. For example in the case of mocha. This resulted in
bad rerun snipptets:
```
bin/rails test app/models/deliveries/delivery.rb:103
```
Let's always use the first line of the failed test-case in our rerun
snippet. We can display the line number of the assertion error elsewhere.
|
|
|
|
|
|
|
|
|
|
|
| |
Previous commit accidentally broke mixing line filters with string -n filter.
Fix by checking if it is a string and returning it.
We also need to ensure the -n filter carry forward into any other composite filters.
Fix by letting the named filter be extractable, so we'll keep this for the next runnable's
run.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`derive_regexp` was written with the assumption that we were run from a
blank slate — that if the filter didn't match we might as well return it
because it was nil.
This isn't the case because minitest calls `run` on every runnable. Which
is any subclass of Minitest::Runnable, such as ActiveSupport::TestCase,
ActionDispatch::IntegrationTest as well as any inheriting from those.
Thus after the first `run` we'd have put in a composite filter in
`options[:filter]` making the next `run` create a linked list when it
failed to match the regexp and put the composite filter as the head.
Every runnable would accumulate more and more of the same filters,
which effectively acted like an expanding whitelist and we ran tests
from other runnables.
Clog the accumulation by returning nil if there's no filter to derive
a regexp from.
Note: we pass a seed in the tests because Minitest shuffles the runnables
to ensure the whitelist is expanded enough that the failure is triggered.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If running `bin/rails t test/models/bunny_test.rb:` we'd implicitly run all the
tests in the bunny test. I now highly doubt that people would ever put in a line
filter without a line *and* want that to mean run all tests in that file.
Instead, change regex to require a line digit after the colon, so runs without a
line at the end would fail to require the test file.
This also has the side benefit of breaking requiring a file with many colons:
`bin/rails t test/models/bunny_test.rb:::::::::::::4`
Think this means I've had enough colonoscopy to last me through the year :)
|
|
|
|
|
|
|
| |
Closes #23027.
This does not restore complete backwards compatibility. It simply passes
the contets of the `TEST` env to the new runner.
|
|\
| |
| | |
delete only unnecessary reporter
|
| |
| |
| |
| |
| | |
Reporter that defines its own users at the time of this process are also loaded,
to avoid them from being deleted, to delete only the specified to unnecessary reporter.
|
| | |
|
| |
| |
| |
| |
| | |
It might be tough for readers to know why we implement `===`, and where
the Regexp in `derive_regexp` came from.
|
|/
|
|
|
|
|
|
|
|
|
|
| |
The line filter parsing added to ActiveSupport::TestCase is only half the story
to enable line filtering. The other half, of adding the patterns to the options,
is done in the Minitest plugin that Railties has.
Thus it makes more sense to have the filter in Railties with the other half and
all the line filtering tests.
Move the filter and extend Active Support in an initializer, so that when users
or `rails/all.rb` require `rails/test_unit/railtie` we can still filter by line.
|
|
|
|
|
|
|
|
|
|
|
| |
Didn't like the constant being at the top of the file, gave it overdue importance.
Now that `color_output` expects a result we can shorten some of the flexibility
from earlier:
* Inline COLOR_CODES constant (keep local variable for readability,
but don't need names of colors at run time).
* Inline color variable in `color_output`. Looks just as clear without it.
|
|
|
|
|
| |
Focus `color_output`'s intent on coloring output by a result. We aren't meant
to pass it arbitrary codes to color output.
|
|
|
|
|
|
| |
The word color is being thrown all around with slightly different meanings.
Right now, I understand it. But I'd like to be more immediately clear.
|
|
|
|
| |
I got the blues because we aren't coloring any lines blue.
|
|
|
|
|
|
|
| |
The static red color wouldn't paint skips in their designated yellow.
Use the color name we got from the result label earlier, which marks
skips as yellow.
|
|
|
|
|
|
|
|
| |
I should have replaced the summary reporter with a subclass
the first time I wrote this.
For whatever reason, I didn't. Do it right and slim the methods added
to Minitest in the process.
|
|
|
|
|
|
| |
Minitest by default includes a summary reporter and a progress reporter.
To print colored output, we have to replace the progress reporter.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The errors message only was not displayed, as if it did not use the inline reporting,
modified to also information the method name and the like in error are displayed.
```
# before
Failed assertion, no message given.
bin/rails test test/models/user_test.rb:5
```
```
# after
Failure:
UserTest#test_the_truth:
Failed assertion, no message given.
bin/rails test test/models/user_test.rb:5
```
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the absolute path is not required to re-run the test,
modified so that unnecessary information is not displayed.
```ruby
# before
bin/rails test /path/to/blorgh/test/integration/navigation_test.rb:5
# after
bin/rails test test/integration/navigation_test.rb:5
```
|