Part 1: Data-Binding Frameworks (e.g. AngularJS)

Transcription

1 Miško Hevery: AngularJS & Testability Part 1: Data-Binding Frameworks (e.g. AngularJS) Misko Hevery introduces building an app with AngularJS. To follow along, use the command git clone at Misko defines AngularJS a new open-source flavor of JavaScript, designed to make coding apps easier. Three families of scripting applications have their strengths and weaknesses Browser as dumb terminal, abstract away from HTML/Javascript, DOM manipulators. The Benefits of AngularJS s Data Binding and Dependency Injection Framework Misko codes Hello World in the three languages, showing how AngularJS s declarative data-binding framework greatly simplifies coding. Angular is about teaching browsers new tricks. AngularJS s data-binding framework s efficiency and advantages when compared to jquery are great. AngularJS combines features from Javascript and jquery, bringing together imperative and declarative frameworks. Building apps is more than just DOM manipulation. The script s use of dependency injection makes testing easier. Misko demonstrates how, also showing the agile functionality of the code. AngularJS has testing tools baked in. Because HTML & JavaScript will remain standard, Misko explains why AngularJS embraces the standard but strives to improve on w3c s limitations. Return to introduction to building an app with AngularJS; the standard framework, with testing included. Be sure to enter checkout step f to avoid Misko s alias. Seed apps are included with the software and include test folders with end-to-end and unit testing. From the Scripts folder, open browser and go to local host AngularJS end-to-end testing is ideal for testing AngularJS applications. Misko explains the advantages of Angular s built-in test runner. How to transform static text to dynamic text. Enter checkout step 2 f. Questions from the floor make sure everyone is following. Misko explains how Angular defines new vocabulary for HTML. Angular also uses jquery to increase levels of abstraction. 1

2 AngularJS doesn t require main methods, so main method testing is not required. Declarative data binding and dependency injection allow Angular to work without main methods. Misko runs a short test to demonstrate. AngularJS specializes in Create/Read/Update/Delete applications, at the cost of greater flexibility. AngularJS trades complexity for abstraction and an easy life for developers! Built-In Testing Examples Using AngularJS To perform a test in AngularJS, first, execute scripts/test-server.sh. Point a browser to localhost9876, then click Capture This Browser. From a new tab, execute scripts/test. sh. Misko demonstrates and takes questions. Real-time searches with data binding; a difficult exercise in jquery becomes simple in AngularJS. Misko searches the list of phones in two lines and shows how AngularJS replaces a huge coding task with one line of code. Misko tests the app with a series of scenarios. By the magic of AngularJS, he makes JS wait. Misko explains one of Angular s best innovations: easy testing. The AngularJS testing tools are ideal for Create/Read/Update/Delete type applications specifically. Misko explains how callbacks are handled within AngularJS, and how mockup back- Rather than use a hard-coded data list, the application pulls data from a server. Misko takes more questions, explaining how AngularJS s specific commands work like conventional Java codes. Dependency injection lets you test your app without the actual need for the server to reply. The declarative assembly instructions allow for more creative results, and the built-in xhr mocks allow testing of every crevice of your application. After a short break, Misko explains how the code calls for dependencies, and how the dependency injection knows what to hand the code. Basically, ask and ye shall receive. The code is coded to know what to do. Incorporated links change the URLs for multi-page applications by rejigging the data already on hand. Misko demonstrates from the source code Misko describes deep linking as the big step that makes Angular more than a toy application. The application mimics server-based applications, but wholly within the browser, using the code ng view and the function PhoneCatCtrl to create a new controller. Likewise, coding is similar to round-trip applications, but entirely within the browser. Applications are able to identify the browser type, and switches appropriately between hash bangs and real URL paths. Misko refers to the documentation app at docs.angular. org/#!/api/angular.service.$xhr. AngularJS coding is searchable as well. 2

3 Greater depth in the app-browsing experience leads to a very responsive interactive experience. Misko demonstrates with phone/phoneid and built-in xhr mocks. Misko says you re in a comfortable world of round-trip apps with URLs and controllers while at the same time you re building an xhr app that is very user-responsive. Misko demonstrates filters under phone-detail.html. Also see the page on $filter.number from the reference site. Filters allow you to ascribe special characters to true/false properties, format numbers, let dates be displayed in different ways in different places, etc., and take smaller issues out of the controller s hands. Image selection can be done with a single command: ng:click=setimage{img}. Involved code in plain JS is reduced to a simple high-level command in AngularJS. This can also be tested with the thumbnail image click test script. Answering a question from the floor, Misko explains why page changes in the browserbased applications AngularJS can create are much faster than even the fastest server-side application. AngularJS can be sprinkled onto regular web pages; use as much or as little as you like. It plays happily with other web technologies. Validation of fields can be performed within applications. Misko demonstrates from docs.angular.org/guide/dev_guide.forms. Using the tag span class= error ng: show, you can set specific fields necessary for validation. Server validation is still required in some instances as browsers can t be trusted. Misko explains the handy tag Phone_.query. Simple calls to the server can be made, with the tacit understanding that it will be handled in time. AngularJS is available in two branches, a mostly-stable Branch 9 used in this demonstration and a more experimental Branch 10. A first release version, AngularJS 1.0, is due for release soon (as of January 2012). Answering another question, Misko explains the curry function. Injectors call functions and supply necessary functions. It can also provide some other items it has been instructed about specifically. Misko demos one way AngularJS teaches the browser new tricks. Small amounts of code, in this example the tag my:time, will allow you to create new commands that can be called elsewhere in the app. AngularJS is at its core an html compiler. Misko also talks about Sencha Touch ( sencha.com ). 3

4 Part 2: Q&A on AngularJS How do you sprinkle AngularJS onto a server-side application? The example shows how to call for help text within a static HTML page using the command ng:autobind. The AngularJS sprinkling can load an existing round-trip app or static page with extra content that can be called by a user without further demands on the server. Controller documentation also shows how to sprinkle AngularJS. AngularJS widgets are no longer in the expected release version. Nevertheless, Misko discusses their operation in detail using an example from the reference site. Widgets have been replaced by Directives in AngularJS 1.0, making it far simpler to perform the same functions. To use your pre-existing jquery modules in the AngularJS pages without interference, you can point the AngularJS towards a function that tells it to leave the system alone if another app might cause a conflict. Misko uses the my:time example. How is this better/different from Onclick? AngularJS statements do not operate at a window level. Misko explains how AngularJS has its own lexicon parser that takes it beyond mere html. From GitHub, Misko looks at an independently developed jquery Angular mobile adapter, showing some of the possibilities of AngularJS s open source nature. AngularJS wasn t developed to handle very large databases. Misko says that Angular takes 80% of your coding out of your hands, all the way up to the DOM, and allows you to do it declaratively, leaving you with the remaining 20%, which is still heavy lifting that will have to be done conventionally. Misko gives his opinion of Backbone ( although he admits he hasn t used it. It is a smaller, less-ambitious project. Misko likens Backbone to a hammer and AngularJS to a complete tool kit. Misko explains how AngularJS is being used internally at Google. Some third-party applications have been built in AngularJS but few in the public domain. Go to github.com/ angular/angularjs/wiki/ and search for projects using AngularJS. Misko reiterates that Angular is best for crud applications. Misko is one of only three people working on AngularJS, all by coincidence from Slovakia. They released a new development stage about once a month. How do you get from a conventional HTML + JS web site, and move to something with automated testing? Misko explains that starting with a small project will allow the programmer to gain enough experience to successfully structure the replacement for the original app, in a fully testable environment. But it isn t easy. Misko discusses the challenges of testing the DOM. 4

5 Misko recommends three books about test-driven development: Working Effectively with Legacy Code by Michael Feathers, Growing Object Oriented Software Guided by Tests by Steve Freeman and Nat Pryce, and Test-Driven JavaScript Development by Christian Johansen. Part Two ends. Part 3: The Psychology of AngularJS Testing The three things you need to know about testing. 1. Read the code, 2. Mind your dependencies, 3. Sharpen your environmental Ax. It s easier to do it properly than do it wrongly. It s quicker and easier to write test code than not. While the test code is almost as long as the working code, it s much simpler and quicker to write. Testing needs to be built in from the ground up. When the application is complete, you can t go back and retro-fit the testing. People don t write testing because they don t know how... but this is a secret. Don t be afraid. If you want to test your software, test it at the point of writing. Once it is written, it s too late. How would you make code that is deliberately hard to test? The difficulty is structural. The more layered the dependency, the harder it is to test. With more control over variables, testing is straight forward. Bigger projects are no harder than small projects - there is just more work. Find the stuff you actually need and then work with them. The more nested the dependencies, the harder things will become for you. The magic is in writing testable code, rather than writing code tests. It s not about writing code that pretends to be a user. If you can replace all the other components with dummies, eventually you can break the code down into its simplest parts. Unit tests are easier than end-to-end testing. Only once the components are working properly, can you begin to look at end-to-end testing. How do you test a class? You test it by replacing the class s sub-dependencies with friendly dummy modules. Then everything that goes wrong is in the class under test. The real subdependencies can be plugged back in later. Keep business-logic separate from object graph construction and lookup. Mixing these two types of coding makes testing hard. It s easier to replace real modules with friendly modules. Examples of testing. Testing after the fact means you assume the code works, then try it out. The problem is largely insoluble. Can you write the test before the code? If you write the test first, it will probably be able to survive changes to the code. If you know what the tests are actually trying to achieve - the 5

6 stories of the tests - you ll be able to write code that can be tested by it While simple objects can be trusted to be benign, more involved objects need careful handling. The new operator is best avoided. The graph shows the lines of production code vs the lines of test code. Ideally these should be developed evenly and at the same time. 6