Your SlideShare is downloading. ×
Automated Frontend Testing
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

Automated Frontend Testing

21,570

Published on

A talk about my frontend testing framework: http://github.com/NeilCrosby/frontend-test-suite/tree/master

A talk about my frontend testing framework: http://github.com/NeilCrosby/frontend-test-suite/tree/master

Published in: Design, Technology
4 Comments
43 Likes
Statistics
Notes
No Downloads
Views
Total Views
21,570
On Slideshare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
373
Comments
4
Likes
43
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


  • I’m also lazy.






































































































  • Unfiltered data
    labels pointing to non-existent input elements








  • Transcript

    • 1. Automated Frontend Testing NeilCrosby (Image from “The Korean Robot” - http://www.flickr.com/photos/zebrapares/1344995547/)
    • 2. Who am I? @NeilCrosby European Frontend Architect for Search at Yahoo! I help look after frontend code quality.
    • 3. What’s this talk about? • Automatically and regularly testing frontend code against known standards. • Why? What? How? Where?
    • 4. Why? What? How? Where?
    • 5. Why test? • We all want to write code that works. • Testing improves reliability. • Repeatedly testing minimises regressions. • Automatic testing can pick up “dumb-ass” mistakes.
    • 6. That sounds lovely • Normally that doesn’t happen though. • Normally what happens is...
    • 7. 1. We build things. They adhere to our standards.
    • 8. 2. We go to the pub.
    • 9. 3. Later, we add more code.
    • 10. 4. Our code stops adhering to our standards.
    • 11. 5. Things become less easy to maintain.
    • 12. 6. Bugs creep in.
    • 13. 7. We go to the pub in despair.
    • 14. 8. Repeat.
    • 15. So... • Test automatically and often. • By adhering to a known standard, and constantly testing against it, it becomes easier to spot problems with the code that we're writing.
    • 16. And that saves money Fewer bugs == Less time fixing bugs == More time developing new features.
    • 17. Why? What? How? Where?
    • 18. What’s normally tested Backend Frontend In-Browser (API, functions) (HTML, CSS, JS) (Functional) Validators, JsLint, *Unit Selenium YSlow etc. Sometimes Automatic via CI Manual automatic via CI Adhoc, when Well defined Fairly well defined remembered
    • 19. Why not use Selenium? • Selenium tests code after it’s been interpreted by the browser. • Good for functional testing, not so good for testing discrete units of code.
    • 20. Discrete Units? • I’m looking at testing the quality of our HTML, CSS and JavaScript. • It should all adhere to a known standard.
    • 21. So we’re testing what? • The code that leaves the server. • Before it is interpreted by the browser.
    • 22. What should we test? • Currently I’m testing against: • W3C HTML Validator validator.w3.org • W3C CSS Validator jigsaw.w3.org/css-validator • JsLint jslint.com
    • 23. Validation is a dirty word • People don’t like the word. • They always ask “what if?”.
    • 24. Custom DTD • Custom DTDs can help you create your own internal standard.
    • 25. Custom DTDs are Easy <!ENTITY % HTML.strict SYSTEM quot;strict.dtdquot;> %HTML.strict; <!ATTLIST OL %attrs; -- %coreattrs, %i18n, %events -- start NUMBER #IMPLIED -- starting sequence number -- >
    • 26. Why? What? How? Where?
    • 27. How do I do this testing? • I’ve been writing a test suite! • http://github.com/NeilCrosby/frontend- test-suite (CC Attribution-Share Alike)
    • 28. Currently in Phase 1 • Tests can easily be run against known units of HTML, CSS and JavaScript. • I’m using phpunit as the framework.
    • 29. HTML Testing • By default tests against HTML 4.01 Strict. • Test against custom DTDs. • Module and full page testing. • Test files, URLs or strings.
    • 30. CSS Testing • By default tests against CSS 2.1. • Known exceptions to the standards can be allowed to pass validation. • Test files, URLs or strings.
    • 31. JavaScript Testing • Test against any configuration JsLint allows. • Test files, URLs or strings.
    • 32. Add to your CI • Run these tests in your hourly builds. • Run them as a pre-commit hook.
    • 33. Be a good citizen • You’ll be running these tests frequently. • Set up your own local versions of the HTML Validator, CSS Validator and JsLint. • Instructions available on the web.
    • 34. Running these tests • If you need to test a simple site, it’s easy - pass a config object to TheCodeTrainEasyFrontendTestSuite. • Otherwise, write custom TestCase extensions (still not hard).
    • 35. Including the Suite require_once( 'TheCodeTrainEasyFrontendTestSuite.php' );
    • 36. Creating the Tests class SomeTestSuite extends TheCodeTrainEasyFrontendTestSuite { public static function suite() { return parent::suite(array( ‘html’ => array( ... ), ‘css’ => array( ... ), ‘js’ => array( ... ), )); } }
    • 37. Creating the Tests class SomeTestSuite extends TheCodeTrainEasyFrontendTestSuite { public static function suite() { return parent::suite(array( ‘html’ => array( ... ), ‘css’ => array( ... ), ‘js’ => array( ... ), )); } }
    • 38. Creating the Tests class SomeTestSuite extends TheCodeTrainEasyFrontendTestSuite { public static function suite() { return parent::suite(array( ‘html’ => array( ... ), ‘css’ => array( ... ), ‘js’ => array( ... ), )); } }
    • 39. Creating the Tests class SomeTestSuite extends TheCodeTrainEasyFrontendTestSuite { public static function suite() { return parent::suite(array( ‘html’ => array( ... ), ‘css’ => array( ... ), ‘js’ => array( ... ), )); } }
    • 40. The ‘html/css/js’ arrays ‘html’ => array( ‘validator’ => ‘http://yourvalidator’, ‘tests’ => array( ‘http://someurl.to/test’, ‘file://some/file/to/test’, ‘<p>Some string to test</p>’, ), ‘options’ => array( ... ) )
    • 41. The ‘html/css/js’ arrays ‘html’ => array( ‘validator’ => ‘http://yourvalidator’, ‘tests’ => array( ‘http://someurl.to/test’, ‘file://some/file/to/test’, ‘<p>Some string to test</p>’, ), ‘options’ => array( ... ) )
    • 42. The ‘html/css/js’ arrays ‘html’ => array( ‘validator’ => ‘http://yourvalidator’, ‘tests’ => array( ‘http://someurl.to/test’, ‘file://some/file/to/test’, ‘<p>Some string to test</p>’, ), ‘options’ => array( ... ) )
    • 43. The ‘html/css/js’ arrays ‘html’ => array( ‘validator’ => ‘http://yourvalidator’, ‘tests’ => array( ‘http://someurl.to/test’, ‘file://some/file/to/test’, ‘<p>Some string to test</p>’, ), ‘options’ => array( ... ) )
    • 44. The Options Array ‘options’ => array( ‘doctype_override’ => ‘<!DOCTYPE HTML SYSTEM quot;http://site/doctype.dtdquot;>’, ‘document_section’ => TheCodeTrainHtmlValidator::HTML_CHUNK, ‘document_section_position’ => TheCodeTrainHtmlValidator::POSITION_HEAD )
    • 45. The Options Array ‘options’ => array( ‘doctype_override’ => ‘<!DOCTYPE HTML SYSTEM quot;http://site/doctype.dtdquot;>’, ‘document_section’ => TheCodeTrainHtmlValidator::HTML_CHUNK, ‘document_section_position’ => TheCodeTrainHtmlValidator::POSITION_HEAD )
    • 46. The Options Array ‘options’ => array( ‘doctype_override’ => ‘<!DOCTYPE HTML SYSTEM quot;http://site/doctype.dtdquot;>’, ‘document_section’ => TheCodeTrainHtmlValidator::HTML_CHUNK, ‘document_section_position’ => TheCodeTrainHtmlValidator::POSITION_HEAD )
    • 47. The Options Array ‘options’ => array( ‘doctype_override’ => ‘<!DOCTYPE HTML SYSTEM quot;http://site/doctype.dtdquot;>’, ‘document_section’ => TheCodeTrainHtmlValidator::HTML_CHUNK, ‘document_section_position’ => TheCodeTrainHtmlValidator::POSITION_HEAD )
    • 48. Options? • Custom doctypes, full page or module, position on page. • Options can also be given for individual tests. array( ‘file://some/file/to/test’, array( your_options ) )
    • 49. Running these tests > phpunit SomeTestSuite PHPUnit 3.3.1 by Sebastian Bergmann. ......... Time: 7 seconds OK (9 tests, 9 assertions)
    • 50. Some failures ....F..... Failed asserting that Array ( [0] => Array ( [line] => 7 [errortype] => [error] => syntax of attribute value does not conform to declared value [original_line] => <label for=quot;quot;>Some label</label> ) ) is false.
    • 51. Some failures .....F.... Failed asserting that Array ( [0] => Array ( [line] => 1 [errortype] => parse-error [error] => Value Error : display (http://www.w3.org/TR/CSS21/ visuren.html#propdef-display) inlin is not a display value : [original_line] => p ) ) is false.
    • 52. Why? What? How? Where?
    • 53. Where’s this used? • Yahoo! - SearchMonkey • TheCodeTrain.co.uk’s WordPress theme.
    • 54. It’s found problems • Security holes. • Form usability issues. • Other suspect HTML.
    • 55. The Future!
    • 56. Phase 2 - The Future • Test for things a simple DTD check can’t pick up on. • CodeSniffer. • Whitelisting sections of code - e.g. adverts. • Basic accessibility testing - working with the experts at Yahoo!.
    • 57. Available Online • This talk: http://icanhaz.com/aft • The Code (please fork and contribute): http://github.com/NeilCrosby/frontend- test-suite • Twitter: automated frontend testing, @NeilCrosby • My blog hub: http://neilcrosby.com

    ×