The document discusses Test-Driven Development (TDD). Some key points:
- TDD involves writing automated tests before writing code to ensure tests fail initially and then passing the tests by writing just enough code. This prevents writing extra code and helps design code structure.
- TDD provides benefits like confidence in code quality, catching errors early, and giving feedback on changes. Unit tests should initially fail, test individual components, and not be for finding bugs which is done through manual testing.
- The basic TDD process is to create a failing test, write just enough code to pass the test, refactor code, and repeat the process for each new feature or change. This helps integrate TDD into
2. what is TDD?
Write automated tests before you
write your code.
Some benefits:
• Do not write more code than needed.
• We have a goal to shoot for.
• You can’t cheat and blow off the tests.
• TDD helps design our code.
3. Why TDD?
Be confident about our code.
Be confident when someone make
changes on it.
Provides immediate feedback for
every change.
4. Why TDD?
Be confident about our code.
Be confident when someone make
changes on it.
Provides immediate feedback for
every change.
5. Bugs
Are a waste of time.
Are expensive to fix.
“If I don’t need to make it work, I
can go a lot faster.”
Kent Beck
6. Unit test must…
Initially fail.
Be orthogonal (independent) to all
the others.
Don’t test configuration settings.
Be not about finding bugs.
• this is done manually by QA.
7. You are not allowed…
To write code unless is to make pass a
failing unit test.
To write any more of a unit test than is
sufficient to fail.
To write any more production code than
is sufficient to pass the one failing
unit test.
8. Basic steps
Create test.
Check that this test fails.
Once the test fails, start coding
until the test does not fail.
Once the code works, clean up,
refactor all necessary.
9. Flow
(Re)Write a test
Test succeeds
Check
if test
fails
Test fails
Write
production
code
Test(s) fail
Run
all
tests
All tests
succeed
Clean up code
10. How to integrate it?
Creating a filter:
angular.module(‘app’, [])
.filter(‘encode’, function() {
return function(input) {
// @todo write the code here
};
});
11. How to integrate it?
Let’s create the test:
describe(‘Testing’, function() {
var encodeFilter;
beforeEach(module(‘app’));
beforeEach(inject(function($filter) {
encodeFilter = $filter(‘encode’);
}));
it(‘should encode a URL with unusual characters’,
function() {
var url = ‘http://www.foo.com/234234/Build & Joneséí%’;
var urlexpected = ‘’;
expect(encodeFilter(url)).toBe(url);
});
});
16. Some examples
Testing a filter:
http://jsfiddle.net/kFLuV/1/
Testing a directive:
http://jsfiddle.net/Fh3V7/
Testing a controller:
http://jsfiddle.net/ntFKL/
Testing a service:
http://jsfiddle.net/B72tr/
Editor's Notes
The ancient Greeks… :D
Very simple methodology.
About feedback, it is more important than we can think, to find a problem when developing is less costly than in further stages.
About feedback, it is more important than we can think, to find a problem when developing is less costly than in further stages.
All we know what are bugs.Find a bug involves too many people working too many hours, for something that, at the moment we don’t know is failing for business logic or because our code is not doing what it should.
1. you can't be confident of your test if it doesn't fail in a so basic case like this.2. do not mix other functionalities, this could make your test more complex.4. Despite that we can think, TDD is not about finding bugs, is more about Designing software components robustly.
2. … and compilation failures are failures.… in one word, FOCUS
4 …BUT do not add any unnecessary features or code
I though that at least we could create the minimum necessary, before create the code.
Refactor? In this case we could comment and nothing more else.
YAGNI: YOU AREN’T GONNA NEED ITSoC: Separation of concerns, divide your system into modules or layers, each with a distinct area of responsibility.