8. How things can go wrong…
// Call x.flub with twice z
function foo(z) {
varx = new X(); // Mmmmmtightly coupled…
return x.flub(z*2);
}
// We want to test if x.flub was called with 14
var back = foo(7);
// But only have „back‟ to test!
November 9, 2011
9. How can we test only our
code?
// Call x.flub with twice z
function foo(x, z) {
return x.flub(z*2);
}
// Test x.flub got called with 14…
varx = new MockX(),
foo(x, 7);
If (x.called(„flub‟).with(14)) {
// a winner!!
}
November 9, 2011
10. Really see this in constructors…
// Ewww – not directly testable
function MyObject() {
this.x = new X();
}
MyObject.Prototpe.foo = function(z) {
return this.x.flub(z*2);
}
var test = new MyObject(),
back = test.foo(7) // cannot test what foo() did
November 9, 2011
11. Inject It - Constructor
// Yea! Testable!
function MyObject(x) {
this.x = x;
}
MyObject.Prototpe.foo = function(z) {
return this.x.flub(z*2);
}
varx = new MockX(), test = new MyObject(x);
test.foo(7);
If (x.called(„flub‟, with(14)) {
// We tested only our function!
} November 9, 2011
12. Inject It - Setter
// Yea! Testable!
function MyObject() { }
MyObject.prototpe.setX= function(x) {
this.x = x;
};
MyObject.prototpe.foo = function(z) {
return this.x.flub(z*2);
};
varx = new MockX(), test = new MyObject();
test.setX(x);
test.foo(7);
If (x.called(„flub‟, with(14)) {
// We tested only our function!
} November 9, 2011
25. „Hidden‟ Dependencies
Private functions are „hidden‟ dependencies
Cannot test by definition!
Make public? Are they part of the public API??
Mock them out?? How??
Refactor private function to be explicit
dependencies
Minimize their use – they cannot be tested
directly
Treated exactly like any other dependency
November 9, 2011
29. Explicit Deps
Problem: Public dependencies
Symptom: Explicitly declared
dependencies
Cure:
• Eliminate tightly coupled code/use
injection
• Pre-load mock‟ed versions of public
dependencies
November 9, 2011
30. Private Deps
Problem: Private dependencies
Symptom: Private methods and
functions
Cure:
• Minimize private dependencies
• Make public dependency
• Use composition to pull in private stuff
November 9, 2011
31. Browser Deps
Problem: Browser dependencies
Symptom: „window‟ or global scope
usage
Cure:
• Eliminate tightly coupled code/use
injection
• Pre-load mock‟ed versions of public
dependencies
November 9, 2011
32. Unit Testing Principles &
Practices
All about dependency management
Identify dependencies and mock
them out
Do not take your environment for
granted
November 9, 2011
Enjoy writing new code, not debugging oldDebugging, fixing bugs, pulling out hair – debugging other people’s codeAs a dev what is the least favorite part of your day? Debugging / documentationWhat is the hardest part of your day? DebuggingMake life better for yourself and othersI like to code – I like to move forward & get things done – debugging in moving backwardsDebugging can suck – debugging other peoples code does 4 sure
Any kind of test – unit – integration - functional
Get manager-speak out of the wayYou have heard all of this before from industry – from manager – from co-workers - there’s a reason: less pain for you – less pain for you managers – better codeWhy everyone all up in me about these things?You probably already agree it’s a good thingmanagers NEED you to succeedSmall = testableSimple = testable – minimize side effects – side effects harder to test – harder to capture – harder to explainLoosely coupled
Lots of little – no bigPer function – test ONE THING AT A TIMEDo no create - injectIsolate what you want to testMocking out dependenciesCreating causes tight couplingClever comes later – if at all – don’t get cute or too clever – optimize LATERGet clever later
NOWDon’t have to test first – just now
Unit Testing = Isolating & Mocking & dealing with dependenciesYour code has dependencies you need to be aware of
Everyone talks about tightly vs loosely coupled – this is tightly coupled!Basic dependency injection – otherwise tight dependency couplingWhat am I actually testing? This function needed to pass z*2 to X’s flub functionI pass in a mock & an test it did the right thingTight coupling between foo() and X()
Basic dependency injection – static languagesWhat am I actually testing? This function needed to pass z*2 to X’s flub functionI pass in a mock & an test it did the right thing
Basic dependency injectionWe really see this in constructors!!! Sometimes in methodsWhat are you gonna test?? Object X hidden away
Constructor injection –a solution from static languages - We really see this in constructors!!! Sometimes in methodsConstruct objects with their dependencies – which can be goofy – the caller or constructor now needs to know the object’s dependencies!
Setter injection – which to use depends on you & api – prefer constructor – static languagesDepends also if dep is available at construction timeMaybe the setter can only used for testsConstruct objects with their dependencies
Debugging, fixing bugs, pulling out hairAs a dev what is the least favorite part of your day? Debugging / documentationWhat is the hardest part of your day? DebuggingYUI / Javascript lets us be smarter / not have to change our function / constructor signatures
Really really see it in YUI3 codeDeclare YUI3 deps & instantiate themYUI ensure something called a, b, c loaded via mods file or already thereThe load step & then tue ‘use’ stepWe just talked about this being a bad pattern – what can we do?
What about injection???If we inject then our CALLING function needs to know all the deps for myObjectRequires statement now gone!Should we inject???? Is this really what we want?myObject no longer self-contained
Now ready to test myObject!Just pushed deps up to script tags‘YUI3’ injectionIsolating objs using script tagsPre-load the mocks before the ‘real’ objects so YUI3 won’t get them
If we inject then our CALLING function needs to know all the deps for myObjectRequires statement now gone!Declare deps and inject!You might be tempted to do this – hopefully you don’t need to!
Does not have to be constructor injection!!This is better but still adds to our code – makes our code more modular however
A better way – isolate mocks with loaderIf you mock all of your objectsShould mock every object when you make oneOR let YUI create script tags for you using modsUse advanced loader features to inject mocks instead of the ‘real’ thing using ‘filter’ http://randomgoo.blogspot.com/
A better way – isolate mocks with loaderIf you mock all of your objectsShould mock every object when you make oneOR let YUI create script tags for you using modsUse advanced loader features to inject mocks instead of the ‘real’ thing using ‘filter’ http://randomgoo.blogspot.com/
Debugging, fixing bugs, pulling out hairAs a dev what is the least favorite part of your day? Debugging / documentationWhat is the hardest part of your day? Debugging
Mock object – NO DEPS!!Save as toolbar-mock.jsEVERY OBJECT SHOULD HAVE CORRESPONDING MOCK OBJECT!This is for testing DEPENDENCIES OF TOOLBAR NOT for testing toolbar itself!!
However you get it on the page….A is a dependency of MyObjectConstructor injectedMocked DEP NOT OBJ!
Debugging, fixing bugs, pulling out hairAs a dev what is the least favorite part of your day? Debugging / documentationWhat is the hardest part of your day? Debugging
No literally hidden!ONLY test PUBLIC functionsUse the YUI augment or plugin or other way to mix in your private stuff info the object – then they can be tested in isolation
ONLY TEST the PUBLIC parts of YOUR APIMENTION YUI PLUGIN AGGREGATION…Well not directlyInject them or minimize? They are a dependency black boxSince they are only used by your code – if you exercise your code you will exercise themPrivate functions are internal apiIf you got a lotta hairy ones refactor:
Isolate ‘window’ object or make all in a single moduleInject window object or centralize itLets you test in env w/o ‘window or a ‘complete’ window objectKRAPLOAD of stuff in ‘window’!!Want to test that we’re callingwindow.escape with the right thing – maybe can tell from return value – maybe notEsp. stuff like local storage or xmlhttprequest or websockets
Debugging, fixing bugs, pulling out hairAs a dev what is the least favorite part of your day? Debugging / documentationWhat is the hardest part of your day? Debugging
Unit testing is testing functions in isolationBut dependencies – which everything has – can be pain pointsHow about zero dependencies???Ride JS to a conclutionYUI3 is a service locatorMORE smaller modules!! Use YUI ‘use’ & composition to build them!
Can’t test!
Unit testing is testing functions in isolationBut dependencies – which everything has – can be pain pointsHow about zero dependencies???Ride JS to a conclutionYUI3 is a service locator
All about dep managementIdentify deps & deal with themDo not require/assume global variables – your module is a black boxAllow for headless tests
Debugging, fixing bugs, pulling out hairAs a dev what is the least favorite part of your day? Debugging / documentationWhat is the hardest part of your day? DebuggingWorst part debugging your codeEven worser part debugging someone else’s code – don’t be that someone else!Make life easier and better for yourself and your co-workers by having tests in place – writing simple & obvious code = testable code
All about dep managementIdentify deps & deal with themDo not require/assume global variables – your module is a black box