dschinkel

import org.junit.Test;
import static junit.framework.TestCase.*;

/* requirements: Implement the following behavior: 
    set() - creation with or without specified size
    add()
    clear()
    contains()
    isEmpty()
    iterator()

dschinkel

/*
    This list will be continually updated with new templates.
    
    If you have requests for any, please add a comment using the comment box at the bottom of this page.
    
    NOTE: the comments are just to facilitate reading this gist, don't include those in your IntelliJ Live Templates.
          some comments are just suggested template abbreviations for the live templates once you add them to your IDE

    OSX templates file location examples: 

dschinkel

/* 
   Tools: mocha, chai-enzyme, jsdom, airbnb enzyme 
   
   Using WebStorm test runner and WebStorm to write code.  
   For the prod code, using Flow for type checking 

   These are isolated unit tests (not integration) that test behavior for particular React components
   
   A big reason why I like React.js vs Vue, Angular, or other types of frameworks or 
   libraries is the simplicity at which you can test behavior.  Also there's no magic going on here in terms of

dschinkel

The Ultimate Unit Testing Cheat-sheet

For Mocha, Chai and Sinon

using mocha/chai/sinon for node.js unit-tests? check out my utility: mocha-stirrer to easily reuse test components and mock require dependencies

---

• Sinon Chai
• Chai
• Sinon
• Mocha

dschinkel

##Chai Expect

##Language Chains

• to
• be
• been
• is
• that
• and
• have

dschinkel

// a "dumb/presentational" React Component

import CompanyHeader from './CompanyHeader';
import CompanyProfile from './CompanyProfile';
import InterviewContentMain from './InterviewContentMain';
import Main from '../Main';
import MainLayout from '../MainLayout';
import React, { Component } from 'react';

dschinkel

import { createStore, expect, mount, nock, Provider, React } from 'test/test.helpers';
import axios from 'axios';
import LiveScreen from 'app/screens/Live/index';
import httpAdapter from 'axios/lib/adapters/http';


axios.defaults.adapter = httpAdapter;

describe('Live Screen', () => {
  it.only('renders a loader', () => {

dschinkel

/*
  Before we venture on trying to refactor a 1500 line React Container that's a mess, we have to add some high level
  unit tests to give us some kind of confidence during small refactorings.
  
  If we had TDD'd this originally, it wouldn't have been a 1500 line container and instead we'd have a bunch of nice little
  simple tests, and our code would have been extremely modular, unlike this legacy container
  
  Because this container is doing too much, we end up also having to mock a ton of shit, that we'd otherwise not need to 
  do if we had TDD'd this because our modules would be super small, therefore tests woudld be 10x simpler and testing very
  small pieces of behavior.  Here, we've had to mock (dummy) several collaborators with arrow functions becasue the code we're testing at a high level

dschinkel

TDD 
---------------------------------------------------------------------------------------------------------------------
Tests and the Red | Green | Blue cycle put pressure on your design all the time as you code.  Your design decisions are guided by that pressure.

As Corey Haines once stated: "It's like having a little buddy as you code, helping you along, 
pointing things out such as when your design sucks, when you've broken something, etc."

- forces you to only create enough code to make a test pass (you’re keeping lean all the time)
- you won’t be able to write the next test if you have code that’s too coupled
- you’ll know immediately when you’ve broken behavior.  This is different than test after. 

dschinkel

/*
  Someone: "But Dave that’s an integration test.  I thought you said integration tests are a scam!!!”
  Dave: "they are for the most part.  And my preference is not to focus or start on those first, those come after you TDD
        a feature (after you have TDD, micro tests are done).  And... I find it usually not necessary to tack on 
        integration tests...when I do they're only a handful.  BUT when you have legacy code that’s a mess and 
        not decoupled and has NO coverage, that’s sometimes the first test you have to write on that kind of code…so 
        that you can have _some_ confidence when you start making little refactorings to start breaking it down”
*/
import { createStore, expect, mount, Provider, React } from 'test/test.helpers';
import Live from 'app/screens/Live/index';