Create test suite foundation

[maclover7]

No description provided.

[guilleiguaran]

#4 was closed because it includes a test_helper but doesn't include any actual test, I think this should include a meaningful test before of being merged 😊

[maclover7]

@guilleiguaran I'm working on adding tests right now locally, wanted to get the setup code merged in first, since they are separate concerns

[rafaelfranca]

If code is not being used there is no reason to merge so even that they are separate concerns, test setup and tests should be in the same pr.

…

On Sun, Dec 11, 2016 at 10:53 AM Jon Moss ***@***.***> wrote: @guilleiguaran <https://github.com/guilleiguaran> I'm working on adding tests right now locally, wanted to get the setup code merged in first, since they are separate concerns — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#17 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC66LloYZzBz0mUJJ8l_7i_fqCONCshks5rHBxvgaJpZM4LJ8_M> .

[dleavitt]

Not sure what the strategy for testing this is going to be, but I made an app for manually testing the gem here:
https://github.com/dleavitt/webpacker-testcase

Happy to adapt this into the beginnings of a test suite if the using a small rails app as a fixture is a useful approach.

[p0wl]

I think it would be great to have testcases for webpacker, and I'm willing to help! Can you create an issue to describe your thoughts on testing webpacker?

[ytbryan]

Just to share this snippet of ApplicationSystemTestCase I'm using.

Assuming you have a frontpages controller, it works with current default pack for react/vue. I can't seem to compile angular.

require "application_system_test_case"

class FrontpagesTest < ApplicationSystemTestCase
  test "visiting the index (Hello Vue!)" do
    visit frontpages_url
    puts assert_selector "div#app p", text: "Hello Vue!"
  end

  test "visiting the index (Hello React!)" do
    visit frontpages_url
    puts assert_selector "div", text: "Hello React!"
  end
end

Personally, I do not know the best testing strategy for now.

[gauravtiwari]

@ytbryan Why not use client side testing tools (Jest, Enzyme), much faster to build and probably take some load off from Rails tests?

[ytbryan]

yeah @gauravtiwari probably better to have a client-side testing approach for webpackers' app. I just copy and edit some of my testcases I found. Not aiming for best approach there.

[gauravtiwari]

Oh sorry, forgive me :) I didn't mean that way. Great 👍

[snuggs]

@gauravtiwari @ytbryan salute!

Contributor to JSDOM and Rollup.js here. Working on rollup-rails gem Have been watching the traction of this repo issues and thought i'd chime in as testing is approaching rapidly. I concur with having client side tests for this. However would not recommend JEST or the similar in regards to vendor lockin. I'd say jsdom is the way to go in this case (possibly mixed with TAP but that's personal preference). We've been following the WHATWG specs to a T and the maintainer Domenic sits on WHATWG and ECMAScript board. That was all I needed to know to start using JSDOM in my Rails apps. Consider him the Aaron Patterson of the DOM. (and someone you should follow if you're not already). There's much we can get for free just by adhering to specs than to jump on what (sounds) popular now.

Back to JS package testing. I used to use PhantomJS but truth be told 90% of it's features (and bloat) aren't needed (except for that aristocrat that actually NEEDS visual renders from tests). I have been duck taping some patterns I use with ES6 and Rollup.js with Buble transpiler. (need to update upstream repo but https://github.com/snuggs/buble-tape) I'm getting a tiny 5kb bundle that runs all my tests in browser (or not) and only dependencies needed are rollup, jsdom, and tap(e). for "unit" and "acceptance" tests of my DOM components. (hit me up to show you how). In no means is this a recommendation to bike shed. It's just a reminder that in this space you usually need 50%+ less than you think you need. But you don't know what you don't know.

Jest i've dealt with it for months and feels much like protractor. I cannot express enough how the best thing for this project is to stay as lightweight and close to the HTML / DOM Living Standard specs maintained by the WHATWG. We also maintain the upstreaming of test cases to the web platform tests. These tests are what the browsers use to test their adhering to the WHATWG/DOM Living standard.

Oftentimes patches to JSDOM get upstreamed into the web platform tests as you can see in my PR implementing the window.CDATASection Interface on the DOM. jsdom/jsdom#1649

What this means in english is you always will use a tool that is the most up to date by the latest WHATWG/ECMAScript specs for the platform which is what you're testing anyways! All the tools mimic the DOM. I'd rather stick with the strategies of the people who implement the specs than a tool that recreates the wheel. Same holds true with every single front end framework out there. Our future selves will thank us.

The DOM now follows WebIDL specs and as the ECMA/DOM specs matriculate we usually downstream to JSDOM or upstream to the Web platform tests.

Just to give you a heads up because the front end is nowhere near the same as it was 2 years ago in regards to accessing the dom (in the proper way) via Rails applications. There is some overlap with concerns as this is focused on webpack. But testing frontend code in Rails itself leaved much to be desired in the past. Now we have an opportunity to change that.

Will star this pull to get notifications. If there is anywhere I can help in regards to getting this testing going let me know where I can fit in.

Peace and Hair Grease fam! 💪

[gauravtiwari]

@maclover7 Closing this one. We have test suite setup now #259 and #299 🎉 👍