Add a simple profiling system to liquid rendering. Each
liquid tag ({{ }} and {% %}) is processed through this profiling,
keeping track of the partial name (in the case of {% include %}), line
number, and the time it took to render the tag. In the case of {%
include %}, the profiler keeps track of the name of the partial and
properly links back tag rendering to the partial and line number for
easy lookup and dive down. With this, it's now possible to track down
exactly how long each tag takes to render.
These hooks get installed and uninstalled on an as-need basis so by
default there is no impact on the overall liquid execution speed.
Three tests in the test suite use the Liquid::Template.register_filter
function to register custom filters with Liquid::Strainer. The problem
is that these register_filter calls leave the Liquid::Strainer object in
an altered state.
As an example, the FiltersTest's test_local_filter relies on the default
behavior of Liquid::Strainer operator, and the test was failing if
register_function had been called earlier. The same thing was happening
with FiltersInTemplate's test_local_global.
The problem was present when the Filters test classes were loaded inside
a single ruby process that also loaded HashOrderingTest. One example is
"rake test", which runs "require" on every test file. Another basic
example is the following command:
ruby -Itest -e "require 'integration/hash_ordering_test';
require 'integration/filter_test'"
Update the tests to always reset Liquid::Strainer's filters back to the
default list of filters.
With this change, FiltersTest and FiltersInTemplate now pass.
Two tests in IfElseTagTest each set a custom operator function for the
"contains" comparison operator.
The problem is that IfElseTagTest was clobbering the original operator
in Liquid and leaving it in an altered state.
As an example, ConditionUnitTest's test_contains_works_on_arrays relies
on the specific behavior of the "contains" operator, and its
test_contains_works_on_arrays was failing.
The problem was present when both test classes were require'd inside a
single ruby process. One example is "rake test", which runs "require" on
every test file. Another basic example is the following command:
ruby -Itest -e "require 'integration/tags/if_else_tag_test.rb';
require 'unit/condition_unit_test.rb'"
This would cause test_contains_works_on_arrays to fail.
Update IfElseTagTest to avoid clobbering the "contains" operator.
With this change, ConditionUnitTest's test_contains_works_on_arrays now
passes.
Ruby 1.9+ uses Minitest as the backend for Test::Unit. As of Minitest 5,
the shim has broken some compatibility with Test::Unit::TestCase in some
scenarios.
Adjusts the test suite to support Minitest 5's syntax.
Minitest versions 4 and below do not support the newer Minitest::Test
class that arrived in version 5. For that case, use the
MiniTest::Unit::TestCase class as a fallback
Conflicts:
test/integration/tags/for_tag_test.rb
test/test_helper.rb
Florian Weingarten