Review how to test Node.js code. This alone is a massive topic, but we can look at some examples, try to map your current approach to testing browser code and find as graceful a translation as possible.

Using any transpilers like Babel/Traceur, CoffeeScript, Elm, PureScript, ClojureScript?

We can discuss:

• Writing tests in the same or different language as the production code
• Optimizing feedback loops
• All the trade-offs therein

Discuss how teams are currently compiling static assets for the web and how they might be improved, reviewing areas like:

• Asset fingerprinting, manifest generations, and CDNs
• Are builds progressive/iterative or all single-shot?
• What are your current feedback loop speeds in development, CI, and deployment?
• What are your biggest pain points?
• How are tests currently integrated?
  • is there a development mode that automatically runs tests on file changes?
  • do development-mode test builds require wasteful build activities take place that aren't necessary (e.g. styles/fonts?)
  • do tests run against the actually-built code or do they duplicatively build the code using their own test-scoped transpilers, potentially letting bugs through (e.g. how karma plugins tend to compile separately from the main app)

• Identify the layers
• Defining a test type that targets an individual layer
• Why consistency matters
• Trade-offs between design and safety link
• My default advice free of situational context

We'll discuss why consistent-but-mediocre tests are almost always preferable to brilliant-but-creative tests within a suite.

• Necessary & Sufficient
• Memes like Subject/Result/Shape
• Defining a discrete set of test suites by type, figuring out what test layers to avoid

I recently did a screencast series on how I prefer to practice TDD, and it iterates pretty dramatically beyond popular Detroit-school TDD.

I'd be glad to share what I find to be the merits of this technique, break it down, demonstrate it in JavaScript, and lead an exercise on it.

There are lots of tools for writing Browser-automation tests in JavaScript, some integrating with test libs like mocha/jasmine/qunit, some that roll their own DSLs. Some examples:

• Nightwatch
• Zombie
• Casper
• Protractor
• The Intern
• Testium

I have project experience with most of these and can offer some advice and help on which to use (and why I currently tend to use none of them, in favor of Ruby & Capybara). That said, there are some interesting conversations to be had:

• The perceived vs. actual benefit of JavaScripting all-the-things
• The veritable graveyard of undermaintained and abandoned JS-based browser automation tools
• The frustrations caused by the fact that Node.js only exposing async HTTP calls means that using the Selenium wire API requires a new async network request for each-and-every Selenium automation call. This can cause a ton of code organization pain without Promise-based abstractions all the way up.

I recently wrote a new test double library called testdouble.js. It's a pretty complete test double library for most purposes and provides a cleaner API than Sinon.js. We can walk through the entirety of it in less than an hour and show how it'd be used in practice.

We have a lot of experience writing browser automation tests in Ruby & Capybara. If that's something folks are interested in, we can peel through examples and help identify low-hanging fruit for improving your tests

How to approach testing (and especially TDD) when using an application framework.

We can discuss specific ones:

• Backbone + Marionette
• Angular
• Ember

And how some framework's provided test types are worth skipping

For any folks doing JUnit & WebDriver for their browser automation tests, we can dig in and look at potetial ways to improve them based on common pitfalls and patterns that have worked well for us in the past.

This will get my own biases and experience on the table and show you how I work in a fresh environment. I'll show you the tools I prefer and do my best to explain why—only briefly contrasting them with alternatives. The goal here is to generate some discussion around how our approaches differ so we can learn from each other.

It's generally very important for tests to control their data, both to ensure reliability (reduce erratic failures and test pollution) but also to maximize expressiveness (the ability to cleanly exercise the behavior you want to observe).

In unit tests, this is normally a function of building clean APIs that require a minimal amount of arrangement.

The challenge increases as tests become more integrated. A number of issues become interesting:

• Factories, Fixtures, and their drawbacks
• Creating, managing, and loading test databases
• Writing tests of remotely deployed systems, locally running systems in a separate process, and running systems in the same process
• Controlling test data for integration points you don't own (e.g. third party APIs)

It's really easy to assert the state of the DOM using jQuery's API, but it can be challenging to set up the same degree of specificity as tersely in your test setup. To that ends, I published jasmine-fixture years ago and we can walk through both how to use it and why it's superior to managing a set of shared view fixtures (or attempting to test against your app's actual views in unit tests)

https://github.com/searls/jasmine-fixture

There are a handful of pieces of general advice for writing solid browser automation tests we can review:

• Selecting on user-visible text, and falling back on semantically meaningful attributes like rel as opposed to IDs & classes that are potentially significant to the implementation
• Automating a11y testing
• Superlinear build growth due to naive CRUD feature testing
• After-action reports to actively identify and work to prevent against false negative test failures
• Time-boxing the overall build to guard against bloat and ensure fast feedback

As quickly as possible, we'll review some good important background topics:

• Arrange-Act-Assert
• False/True Negative Analysis
• Meaningless test data
• Symmetrical unit tests
• The various types of test doubles

• Using ES6 modules with esparanto?
• Using CommonJS modules with Node.js and/or browserify?
• Using AMD with Require.js?

We can discuss ways to test code that's organized into modules, including:

• Whether and how to organize your test code into modules as well
• How to replace a module's dependencies with test doubles using sandboxed-module or proxyquire

We'll take a survey of the attendees to do a quick show and tell by each group of exemplar tests, test running setups, etc. Then we'll use that as a jumping off point for constructive critique and feedback, while we absorb the context of the situation and try to understand what works and what doesn't.