Your SlideShare is downloading. ×
0
TDD Basics with Angular.js and Jasmine
TDD Basics with Angular.js and Jasmine
TDD Basics with Angular.js and Jasmine
TDD Basics with Angular.js and Jasmine
TDD Basics with Angular.js and Jasmine
TDD Basics with Angular.js and Jasmine
TDD Basics with Angular.js and Jasmine
TDD Basics with Angular.js and Jasmine
TDD Basics with Angular.js and Jasmine
TDD Basics with Angular.js and Jasmine
TDD Basics with Angular.js and Jasmine
TDD Basics with Angular.js and Jasmine
TDD Basics with Angular.js and Jasmine
TDD Basics with Angular.js and Jasmine
TDD Basics with Angular.js and Jasmine
TDD Basics with Angular.js and Jasmine
TDD Basics with Angular.js and Jasmine
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

TDD Basics with Angular.js and Jasmine

5,844

Published on

Basics of TDD with a small example using Angular.js and Jasmine

Basics of TDD with a small example using Angular.js and Jasmine

Published in: Technology
0 Comments
11 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,844
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
85
Comments
0
Likes
11
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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.
  • Transcript

    • 1. TDD (Test-Driven Development)
    • 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); }); });
    • 12. How to integrate it? Now the test fails...
    • 13. How to integrate it? Now let’s write the code: angular.module(‘app’, []) .filter(‘encode’, function() { return function(input) { return encodeURI(input); }; });
    • 14. How to integrate it? Now the test works! Refactor?
    • 15. Concepts!
    • 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/

    ×