Upgrade Navigator to Not Rely On Compass

[Snugug]

We don't want our test suite to be dependent on Compass if our tools are not, we need to be able to test in both Compass and Compass Free environments.

• [ ] Upgrade Navigator to be in-line with the work done in Sassy Maps (Ruby Sass only testing)
• [ ] Provide an option to test with Compass
• [ ] Provide an option to test with LibSass
• [ ] Provide tests for the testing framework?

[metaskills]

Great points!

[Snugug]

@metaskills If you're up for working on this, let's do each as a PR just so there's a 2nd set of eyes on this. You can do it as a branch in this repo or fork and issue a PR; just want a 2nd set of eyes.

[metaskills]

Agreed, I will make progress soon too, traveling to RubyNation tomorrow.

[Snugug]

Awesome. No rush on this, just tracking.

[Snugug]

Hey @metaskills, any update on this?

[metaskills]

Hey Sam! Not yet, I've been up to my eyeballs in living style guide work since. Ah the joys of summer time :/ still on my radar tho!

[Snugug]

np @iamcarrico may jump in and help with this

[iamcarrico]

This is on my radar--- just a little low right now (other Open Source projects also crying for help). When you do get to it @metaskills can you ping me? Would just like some knowledge on what all you did for future reference :+1:

[metaskills]

Give me a few days and I will put some knowledge down. I've come up with a few alternative techniques latently too when working on CustomInk's new living style guide that I think we can use too. Stay tuned.

[metaskills]

Please read this PR for the full details which was basically a navigator repellent. This is main file here that could be abstracted to a gem. The second link is how it would be used in said project (assuming you defined the proper surrounding dirs too).

https://github.com/Team-Sass/Sassy-Maps/blob/0.x.x/tests/navigator.rb https://github.com/Team-Sass/Sassy-Maps/blob/0.x.x/tests/sassy_maps_test.rb

Tho I think this is really clever and I am certainly stronger for understanding how to pipe things thru a TAP protocol, I think we can do better. The main issue I do not like about this testing setup is that it puts all the units into a single diff file. It is hard to state a test name and isolate a certain case to a certain failure. When building the new CustomInk style guide, I came up with the following.

Basically, I am leveraging one of Ruby's heredoc syntax to keep things clean looking. If I used the raw << without the - it would have required the SASS and CSS to be pushed to the far left. I believe this is a much better way to write unit tests for Sass projects. Thoughts?

describe 'string functions' do

  it 'my-sub - subs a string replacement with a value' do
    assert_sass <<-SASS, <<-CSS
      .test { content: my-sub('.my.{{COLOR}}', '{{COLOR}}', blue); }
    SASS
      .test { content: .my.blue; }
    CSS
  end

  it 'my-parse-template - builds on top of my-sub using VALUE for replacement' do
    assert_sass <<-SASS, <<-CSS
      .test { content: my-parse-template('.my.VALUE', blue); }
    SASS
      .test { content: .my.blue; }
    CSS
  end

end

describe 'list functions' do

  it 'my-map-selectors - maps list to a new set of selectors using a template' do
    assert_sass <<-SASS, <<-CSS
      $icons: (phone chat);
      $result: my-map-selectors($icons, '.icon-my-VALUE:before');
      .test { content: $result; }
    SASS
      .test { content: .icon-my-phone:before, .icon-my-chat:before; }
    CSS
  end

end

describe 'color functions' do

  it 'my-alphaize - like rgba() but no alpha and with a default white background' do
    assert_sass <<-SASS, <<-CSS
      .test { content: my-alphaize(#ff6767, 0.2); }
    SASS
      .test { content: #ffe0e0; }
    CSS
    assert_sass <<-SASS, <<-CSS
      .test { content: my-alphaize(#ff6767, 0.2, black); }
    SASS
      .test { content: #331414; }
    CSS
  end

end

describe 'unit functions' do

  it 'my-rem - coverts px to rem or allows rem units to fall thru' do
    assert_sass <<-SASS, <<-CSS
      .test { content: my-rem(16px); }
    SASS
      .test { content: 1rem; }
    CSS
    assert_sass <<-SASS, <<-CSS
      .test { content: my-rem(2rem); }
    SASS
      .test { content: 2rem; }
    CSS
  end

end

[metaskills]

BTW, please keep a lid on this. I have not finished my blog post on this yet.

[metaskills]

Any feedback?

[Snugug]

Are all of the tests now written in Ruby? I don't see it looking into Sass files. Also, how does this work for testing mixins? The examples you've given seem to be for unit testing functions, which is great for functions, but especially with Sass we need integration/regression tests for working with mixins and extends. In Toolkit, for instance, most of what it's doing isn't working against mixin input and calling other mixins; there'd be very little to unit test there, but there's a ton of integration/regression testing. (as an aside, I don't like calling mixin testing integration/regression; do we have a better name? I don't think it's quite unit testing, it may be, but if it is we need a way to describe it).

Could this also not be achieved by simply breaking out the Sass files we've written to only have the individual items? We chose to group the tests together because, well for ease sake, but there's no reason we couldn't break them out into individual files for each test; nothing stopping us. Can the file presented be broken up into many smaller file for ease of maintenance?

One of the things I'd consider highly is that while you may be a ruby developer and writing unit tests in Ruby is close to your core skill set, for many people using Sass (and by many, I mean I can't tell you how many people simply ignore me when I say use Bundler to handle dependencies then complain when things break) is simply an extension of CSS and they'd like something close to their skill set of Sass/CSS and may be turned away from writing tests if they need to use Ruby to do so (regardless of how silly that may seem to you or I). Or consider extending Navigator to being able to test both Ruby Sass and LibSass, would the tests written in Ruby still make sense if they weren't piped to a Ruby parser (BTW, this should be on the roadmap)?

[metaskills]

Are all of the tests now written in Ruby? I don't see it looking into Sass files

Yes and it does use Sass. That detail is hidden away in the implementation details of assert_sass now. I just wanted to keep the discussion high level first, but the idea is that the lower level implementations would allow the testing of everything ever possible that any Sass framework cared to to test.

The examples you've given seem to be for unit testing functions

No, the sky is the limit.

I don't like calling mixin testing integration/regression; do we have a better name?

I agree. TL;DR - Let others worry about naming things.

I hate segmenting tests into more granular categories when they are just different flavors of unit tests. I get it, especially for Sass projects. You may have tests for functions that you can call units and then higher level "integration" or "functional" tests that span the framework. For Sass libraries, I recommend just making that distinction in your file/case names. This is really easy to do with a system like I described above. The author can do what they want. They can put everything in one case, break that case up into distinct describe sections, like one for functions. Or if they want, then can create distinct files for unit and integrations. Either way, the test framework we expose should not care.

Could this also not be achieved by simply breaking out the Sass files we've written to only have the individual items

I am in favor of not doing that and allowing the minitest case do the work of organization. This has numerous benefits too.

• Focus on one test using minitest-focus.
• Focus on a case (file) vs the whole suite.
• Leverage minitest test name as a full description of what you are testing. Lost in the diff method. Hard to attached good error messages, etc.
• I can come up with more if needed. I really think it will pay off.

may be turned away from writing tests if they need to use Ruby

I can empathize with that. However, they still need Ruby to run the tests either way. But yea. I get it. I do feel that many people can easily approach this and just cargo-cult/copy-paste the method and fill in the lines. I even wrote the implementation of assert_sass to ignore white space too.

For those being persnickety like myself, the args to assert_sass are technically backwards. Like assert_equal it should be expected first and actual second. How does this look to you?

assert_sass <<-CSS , <<-SASS
  .test { content: 2rem; }
CSS
  .test { content: my-rem(2rem); }
SASS

Tho technically correct, I prefer the incorrect SASS first arg then CSS second.

[metaskills]

PING! Just finished up my blog redesign (metaskills.net) and now have some more free time. Any feedback from above?