Sass Version Compatibility about sass-spec HOT 9 CLOSED

The intention was the config method (json!)... that we'd bunch new feature tests into a folder and then have a config in the root of it that declares the API-level.

Also, we have to have config to test different output styles, etc.

from sass-spec.

@hcatlin I don't understand how that would work. It seems to be based on either duplication or an assumption that something that works one way in one version will work the same way in other version. Both of which seem bad. Can you explain further?

from sass-spec.

Yes, I am assuming backwards compatibility, generally speaking.

But, it could be like this.

/spec
/pre-4.0/
config.json => {version: "< 4.0"}
test1/*
test2/*
/new-nesting/
config.json => {version: ">= 4.0"}
....
compressed/
config.json => {style: "compressed"}
...

..blah, blah, blah. The folder is only executed if the current running
environment matches it. Luckily, Ruby has its awesome semi-built in
Gem::Version comparators that make this kind of thing easy.

On Thu, Aug 1, 2013 at 12:50 PM, Chris Eppstein [email protected]:

@hcatlin https://github.com/hcatlin I don't understand how that would
work. It seems to be based on either duplication or an assumption that
something that works one way in one version will work the same way in other
version. Both of which seem bad. Can you explain further?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-21964716
.

from sass-spec.

So the thing is that probably 95% of the tests in pre-4.0 will be perfect and apply to 4.0 as well. The base assumption that the same test should work the same in all versions of sass is a good one and so, I think an arrangement where the exceptions to that rule are handled on a test-by-test basis seems good to me. Or maybe there could be a way to inherit config from the directory to the test.

from sass-spec.

My point with that example is that if you wanted to break it.

You could do it in individual tests or in directories.

We use a similar system at Moovweb. Very flexible.

Personally, I prefer things to work the same.... always.

On Thu, Aug 1, 2013 at 1:01 PM, Chris Eppstein [email protected]:

So the thing is that probably 95% of the tests in pre-4.0 will be perfect
and apply to 4.0 as well. The base assumption that the same test should
work the same in all versions of sass is a good one and so, I think an
arrangement where the exceptions that rule are handled on a test-by-test
basis seems good to me. Or maybe there could be a way to inherit config
from the directory to the test.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-21965477
.

from sass-spec.

If it's a pressing feature, I can look into adding another file to each test directory for config options and adding an option to the testing script for the compatibility to run the test at. For example, if the config file exists, it would read it to figure out the compatibility range (e.g. 2.1 - 3.1) of a test, skipping it if the test was being run at a compatibility outside the range specified by the test. If the config file isn't present, it would assume it had full compatibility and run it regardless of compatibility you run the script at (maybe there could be a flag that makes it skip the tests without config files (or make skip the default and run when you set a flag)). The only problem I can see with this is it would require the test-suite to have someone upkeep it and make sure the values are set correctly and that it might be a pain in the butt if you want to say compatibility for versions 2.1 - 3.1 except version 2.2, 2.3, and 2.5 (although I'm not sure if that would ever be needed). Re-reading one of Hampton's comments, I could try to allowing config-ing entire subfolders (hopefully that wouldn't be too hard). I'm not entirely sure how to change the version of sass being used, but if I knew how to from the command line, I could fairly easily make the script able to.

Edit: I'm also working on making it "cleaner" (don't expect a ruby newbie (hey, that rhymes!) to write stylistically "correct" Ruby)

from sass-spec.

What about using control directives in the comment block at the top

/*
 * Version=3.2
 */
.foo {
  // Simple test here
}

That would allow the test suite to keep the tests under the functional areas but be skipped depending on the spec being tested.

from sass-spec.

Because the behavior of Sass does change in backwards-incompatible ways between versions, I think it's probably not possible to assume tests will always work into the future.

I like @nschonni's suggestion of scoping version support to the test itself. Typical version matching, like Ruby's Bundler or node's npm, would allow us to be pretty flexible about specifying when a test should be run or skipped. (A line comment is probably preferable to a block comment, because a block comment would be assumed to be output in the generated CSS.)

The compatibility version would be passed to the test runner, otherwise the runner would match all versions.

I would rather not allow setting version compatibility for an entire directory, as there would then be two code paths for determining version, and seeing the version compatibility explicitly in the source is helpful. Updating version support for tests in bulk could be done by a find/replace without too much trouble.

from sass-spec.

decided that trunk development works better and we have language versions that select specs to run.

from sass-spec.