Craig Freeman
Front-End Developer at Kenzan
"A software development process in which the smallest testable parts of an application, called units, are individually and independently scrutinized for proper automation."
Often automated (almost always) automated.
Often because the code is poorly written (highly-coupled) and the programmer doesn't fully understand what the code is doing.
Programming is generally a series of small experiments - trial and error
When we don't have a clear picture of what we want to accomplish, the task could take a long time.
Positive Tests:
What do we expect to happen if the application is working?
Negative Tests:
What do we expect to happen if the application is not working?
Exception Tests:
What do we expect to happen if the application differs from what we expect?
Three A's:
Arrange - Act - Assert
// Arrange
var value = 9;
// Act
var result = doAwesomeThings(value);
// Assert
expect(result).to.be(value);
Canary test - make sure things are working
describe('awesomeFunction()', function () {
it('should pass the canary test', function() {
expect(true).to.be.true;
});
});
Publicly-available methods and their interactions.
Private methods are generally implementation methods which are hidden from users and breaks encapsulation. Helper functions for the public functions.
Interactions with other methods should be mocked and those methods should have their own unit tests.
Fakes, spies, mocks, stubs. Test-doubles to allow the test to concentrate on the main function without outside variables.
(TDD)
"A software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards."
tl;dr
Red - Green - Refactor
Prime factors