Today we'll be looking at object responsibilities, documenting our code, and an introduction to testing.
When working with Objects and functions, you should try to limit the responsibility of objects as much as possible. Whenever possible, limit your functions or objects to a single role or use.
Deck.prototype.setup - extract buildDeck functionandWhen planning out the objects for an application, it is also important to know what each object can talk to.
Docblockr in ST3npm install -g testem - Runs our tests and reloads on each saved filebrew install phantomjs - Browser that runs from the command linetestem.json - configures testem"framework": "mocha+chai" - sets what test framework we are using"src_files" - what files to include in our tests"launch_in_dev": ["PhantomJS"] - where to run our testsdescribe - creates a unit (what function or object are we testing?)it - creates a single testbeforeEach - set up to do before every test in the current unitChai sits on top of mocha and is what checks if things are returning what they should.
Think that Chai wraps console.assert BUT A TON BETTER!!!
expect you give me _ backexpect style testing.to.be.been.is.that.which.and.has.have.with.at.of.same.a - checks the expected type.ok - expects a truthy value.true - expects === true.exist - expects not undefined or null.equal - expects === to provided value.instanceof - expects instanceof a constructor.property - expects a property (optionally checks if that property is equal to a value)Card, Hand, Hand.prototype.addCards, Hand.prototype.resetCardsAs a way to move things forward, we can start by writing our tests first. Then as we describe the way that our objects should behave, we can write code to make this happen.