Hello dear friends, it's been a while! A year. It's been a year.

Today I've come not to share from the largesse of my stores of wisdom, but to get you to proofread something for me. You see, I am scheduled to present at the Houston.js meetup in October on testing. And for the second half of the talk, instead of lecturing, I'm trying to foster a community discussion on testing.

In support of this goal, I've decided to make a sort of icebreaker handout to help guide the discussion if no one wants to talk. And this is where you come in--you have the unique and limited-time opportunity to Improve my handout.

How you can help: just think of what you'd want to tell a group full of Houston.js attendees. Now cut that thing down to the most important bits so it fits in 5 minutes or less. For the purposes of the handout I have to assume there will be a rowdy, busy discussion, because if it's crickets, I'll just cut early. Then, and here's the trick, think of a question you'd put in a handout to bring you to think about sharing that amazing revelation about testing in JavaScript (or testing web apps in general), and suggest I add that question to the list.

A second, entirely different way you can help: tell me which questions I have that are awful and should be removed. I can take it.

Without further ado, I present the handout (ignore formatting):

Help make us all better by sharing what you know! While I go over Jasmine basics, prepare to answer anything that interests you. My goal is to help draw out the wisdom and experience from the audience (which means you)! Guidelines:

  • Don't feel pressured to answer. Instead, feel free to use this sheet of paper to draw demeaning caricatures of me, or ball it up and throw it at me. Fun fact: both paper and laser toner are good sources of dietary fiber.
  • Focus on how you can help someone else with your knowledge. E.g. we don't care if you use Jasmine or Mocha, but we do care why.
  • Summarize! Try and fit everything into one tweet-length answer. If you can't fit your answer in a single tweet, then ultra-summarize your answer until it does! If it's complex and can't be summarized, try to focus on the benefit you received, and share a link for us to learn more.
  • Tweet at me (@pseale) any links you want me to share with the group.
  • Remember that our goal is to share as much of the group's knowledge as possible—not necessarily by answering the questions below. If you have a unique perspective, by all means share it. If you would like, ignore the questions below and just ask for 5 minutes to talk. Or, feel free to directly ask the crowd a question.
Overall
  1. If you had one tip to give to novice testers, what would it be? If you had one tip to give to fellow grizzled test veterans, what would it be?
  2. Is there a unit testing technique or some learning resource that personally helped you learn unit testing? E.g. an open source project's test suite; a book; a conference video; a kata; a green wristband; ceremonial burning of green wristbands; etc.
Tools, Products, Services
  1. Do you use a CI server? If so, which one, and what is the main benefit? Do you utilize fun gimmicks when a build turns red?
  2. What PAID ($$$) commercial products/services do you use? Please give an experience report, good or bad. (Editor's note: I want to go out of my way to emphasize commercial products because fewer people use them, and so experience reports for commercial products are rare and valuable) E.g. Saucelabs, CircleCI, WebStorm
Browser (end-to-end) Tests
  1. Share any experience you have with browser testing, including:
    • Attempting to set up browser tests, then running into a serious issue, then giving up - if you're brave, we'd like to hear what step caused you to give up.
    • What tool you use, and why it is good for you?
    • If you use zombie.js or a similar browser emulator, have you experienced any gotchas, or has it been all positive?
    • What gives you the most problems attempting to set up browser tests? Or better, is there something you learned that solved a difficult problem?
Integration Tests
  1. If you test your APIs via HTTP client libraries, what are techniques you use to ensure you cover every aspect (security, bad data, junk data)? E.g. “we have shared ‘it' blocks” or “we wrote a giant library of test helpers”. What is the most painful thing about testing via raw HTTP/REST client libraries? Do you have similar tests in your browser test suite?
Unit Tests
  1. Do you write unit tests for JavaScript that runs in a browser (i.e. the front-end)? Do you isolate each piece (or module), or do you test it all integrated? If you've had success doing this, can you explain roughly what your front-end architecture looks like, and how the architecture helps (or gets in the way)? E.g., you can just say “we use Ember”, or “we use the Flux architecture from React/Facebook.” Or “our app is 5000 lines of jQuery in one method, and every night I cry myself to sleep.”
  2. Do you run server-side JavaScript on Node.js and successfully test it? Do you try to isolate every module, or only isolate the boundaries, or isolate nothing?
JavaScript xUnit Test Frameworks
  1. Do you use Jasmine or another JavaScript testing framework? Do you think it makes a difference if you use Jasmine versus Mocha, and most importantly, why? If you have converted a Jasmine test suite to another framework, how hard or easy was the conversion?
  2. Do you use a specific assert library, and if so, why does it matter?