-
-
Save ryanflorence/bba285c1d39b23f42306 to your computer and use it in GitHub Desktop.
var Toggler = require('./toggler'); | |
var React = require('react/addons'); | |
var assert = chai.assert; | |
var Simulate = React.addons.TestUtils.Simulate | |
describe('Toggler', function(){ | |
var toggler, el; | |
beforeEach(function() { | |
toggler = render(Toggler({buttonText: 'toggle'}, 'ohai!')); | |
el = toggler.getDOMNode(); | |
}); | |
afterEach(function() { | |
teardownComponent(toggler); | |
}); | |
it('renders correctly', function(){ | |
assert.equal(toggler.refs.button.getDOMNode().textContent, 'toggle'); | |
assert.equal(toggler.refs.content.getDOMNode().textContent, 'ohai!'); | |
}); | |
it('toggles the content when the button is clicked', function() { | |
assert.ok(toggler.getDOMNode().textContent.match('ohai!')); | |
Simulate.click(toggler.refs.button.getDOMNode()); | |
assert.ok(!toggler.getDOMNode().textContent.match('ohai!')); | |
}); | |
}); | |
function render(component) { | |
var container = document.createElement('div'); | |
document.body.appendChild(container); | |
React.renderComponent(component, container); | |
return component; | |
} | |
function teardownComponent(component) { | |
React.unmountComponentAtNode(component.getDOMNode().parentNode); | |
} |
var React = require('react'); | |
var div = React.DOM.div; | |
var button = React.DOM.button; | |
var Toggler = React.createClass({ | |
getInitialState: function() { | |
return { isOpen: true }; | |
}, | |
toggle: function() { | |
this.setState({isOpen: !this.state.isOpen}); | |
}, | |
render: function() { | |
var content = this.state.isOpen ? this.props.children : null; | |
return div({}, | |
button({ref: 'button', onClick: this.toggle}, this.props.buttonText), | |
div({ref: 'content'}, content) | |
); | |
} | |
}); | |
module.exports = Toggler; | |
@rafaelrinaldi good question that comes up a lot (especially with people new to testing javascript).
Would you test an object that writes to a database without ever asserting the database was updated?
Or, would you not check the values in localStorage
for an object that writes to local storage?
Testing, for me, is about sending inputs and asserting outputs. For a user interface component, the output is the DOM, the inputs are user events (and sometimes method calls).
If my component has a public method to be called programmatically, then yeah, I'll exercise that and validate the output. 95% of the time though any event or method call is going to change the dom representation of the component.
Additionally, by asserting on dom nodes instead of the state of your component you can more easily migrate your tests to other component library implementations.
Oh, regarding "unit" v. "intergration" tests.
Where is the integration in testing the DOM output of a component? It is a unit test. The unit outputs to the DOM. I'm still a little confused why people think that because you have a DOM you are suddenly doing an integration test. Again, the database model analogy, are those integration tests because there is a database around?
@rpflorence The database analogy is great! That's an interesting point of view, Ryan. Thank you :)
It's always difficult for me to create tests that are tied to DOM elements or tests of interaction... Should unit tests cover this scenario? Aren't integration tests more suitable to test this kind of stuff? I'm asking because sometimes when creating tests for components I end up doing some crazy stuff just to simulate states and such.