4. What problem are you solving?
RIA > operations - collaboration:
Spreadsheet, accounting and billing systems, point of sale,
cad/diagramming, chat, games...
Traditional > displaying information:
Searching, shopping, publishing, discussing...
@carlosble
3
5. What do you really need?
RIA
(desktop app deployed in the browser)
●
UX (user experience)
●
Stateful
●
Scalability
●
Real-time
●
Off-line
●
Bandwidth
●
Access to local
hardware
@carlosble
Traditional Web
(UI always processed in the server side)
●
Stateless
●
SEO friendly
●
Synchronization
●
Learning curve
●
Security
●
Compatibility
4
6. Sometimes it's something in between
Listen to your
common sense
When it looks more like RIA:
Still take advantage of what
server side offers
When it looks more like
traditional:
Use progressive enhacement
@carlosble
No, everything does not look like a nail!
5
7. RIA: taking advantage of the traditional way
When it comes to GUI and appearance, you
might go “traditional” first:
- Technical debt on purpose, saves time (well thought out!).
- Changing/Improving that later is not a big deal.
Examples:
●
Server renders js files, js objects, json,... on page load, apart
from HTML and CSS.
●
Page reloads as view changes.
●
Page reloads to get an updated list of items when one of
them is changed.
@carlosble
6
8. Behavior-driven RIA
The business DSL in the step definitions lives in the
browser:
[Binding]
public class UpdateHealthRecords_Steps : RpsEnd2End
{
[Given(@"Bob said his last glucose value was (.*)")]
public void lastGlucoseValueWas(int lastValue)
{
scenarioFixture.lastGlucoseValue = lastValue;
var jsdate = "new Date(2013, 1, 2)";
ExecuteJavaScript(
string.Format(
"rps.Business.addNewGlucoseWith(
{{ value: {0}, date: {1} }})",
lastValue, jsdate));
}
}
@carlosble
Note: Rps is the name of the sample project
7
9. Outside-in TDD starts in the browser
- Domain objects emerge as we test-drive the code.
- The server side becomes just an adapter*, a hub. In
fact, the server side would not be useful at all without the
JavaScript app.
- Risk: duplicated logic in the browser and the hub.
Possible solution: Use Node.js in the hub.
* see hexagonal architecture
@carlosble
8
10. Hub's features will emerge
- Don't start off test-driving it: YAGNI.
- Business rules concerning
security/data-consistency,
are added progressively.
@carlosble
- If you need a RESTful
web API, that might be
a separate application.
- Some data must be
changed by the hub
exclusively. Perhaps
invisible to the app.
9
11. Test-driving a JavaScript application
●
Absolutely everything is testable.
Even test-driving most of it, everytime I feel like testing the
app manually, I can add a test for it (integration tests typically).
●
Event Oriented Programming & Passive view.
Because low levels of abstraction should not know about higher levels.
●
Frameworks? you need widgets.
What do you need an IoC container for?
●
Don't mock what you don't own.
Use wrappers instead.
●
AOP can be implemented with CSS ;-)
Logic should not care about a “modal” window.
@carlosble
10
21. Some references
●
Test-Driven JavaScript Development (book) – Christian Johansen
●
The Cucumber book (book) – Matt Wynne & Aslak Hellesoy
●
JavaScript the good parts (book) – Douglas Crockford
●
JavaScript Allongé (book) – Reginal Braithwaite
●
Enough with the JavaScript already(talk) – Nicholas Zakas:
- Hanselminutes interview.
- Talk.
●
Test-driving events and promises (blog posts) – Carlos Ble
- Promises
- Events
@carlosble
22. Thank you so much
Special thanks to Skills Matter's staff :-D
@carlosble
