Angular just for example, applicable for all frameworks.
HTML was made for scientific documents – it excels here. It’s declarative.
We are building extremely complicated apps on very simple building blocks.
Angular – whole new concept, abstract.
HTML - rather embrace it that wholly abstract it.
DOM manipulations frameworks wouldn’t exist if browser makers did a good job.
Data-binding vs templating frameworks.
Adding craft without actually expressing ourselves.
They are no templates in Angular.
Declarative is great at building UIs, imperative is great for business logic.
Web applications is more than DOM manipulation.
80% of application is now just DOM manipulation – Angular is taking this burden from you.
DI is great for stubbing things → testing.
Magic of testing – writing apps in a way that they are easily tested.
Angular – free to do anything, but packed with good stuff from the start.
W3C is not addressing issues of building real web apps.
git checkout step-0 -f
Why not use Selenium for testing – Selenium is generic framework – it can test any app. Generic is good and bad, it’s not specific to anything.
Define new vocabulary that browser know what to do with it.
In other frameworks, you are merging string and data and producing new strings.
You don’t have to worry about bootstrapping – but you can.
Controllers has to access to DOM.
Abstractions are not free – you loose ability to apply framework to anything.
Think about application, not UI.
SEO is complicated.
Filters – transforming data. Useful for i18n. Specific for views.
XHRs are nice, but resources are nicer.
Promises – returning future.
Backbone is much smaller and it’s purpose is different from Angular.
Because it’s so good for CRUD apps, most of them are not public.
Unless you have done a lot of TDD, it’s not obvious for you when you wanna go with testing.
Working effectively with legacy code http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
Growing Object-oriented software guided by tests http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627
Learn to read the code – read the structure.
Mind your dependencies – determine how code is testable.
Be aware of your environment.
Writing test should be easier than to run app to test a feature.
Indentation code (if, loops, callbacks) are hard to write. Test shouldn’t be indented, should be easy to write.
Testing is like sugar, not like a frosting – it has to be baked in.
Code has to be written in a way that is testable. And you have to write tests to prove that it is testable.
Only valid reason to not write tests is I don’t know how.
What the code does i irrelevant, how the code structured is all that matters for testability.
Analogy: Give a seller money vs give seller a wallet to take money from it.
Unit tests test logic, Scenario tests test wiring.
How can class under test get hold of dependencies: Make it / passed in / from global location
Test should tell a story about what code should do.
You should be able to rewrite entire codebase just from tests.