$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Automated testing
Search
Marc Tamlyn
July 12, 2013
Programming
3
200
Automated testing
They why, what and how of automated testing for a mixed technical and non-technical audience.
Marc Tamlyn
July 12, 2013
Tweet
Share
More Decks by Marc Tamlyn
See All by Marc Tamlyn
Arousal and Anxiety
mjtamlyn
1
80
Working with Children
mjtamlyn
1
91
Wallingford Castle Archers Incorporation
mjtamlyn
0
200
Observation and Evaluation
mjtamlyn
0
120
Weird and Wonderful things to do with the ORM
mjtamlyn
3
1.4k
An Introduction to Graphene and Relay
mjtamlyn
6
1.2k
Tech Interviews that don't suck
mjtamlyn
4
1.1k
Data driven rendering
mjtamlyn
1
190
What's new in Django 1.9
mjtamlyn
1
210
Other Decks in Programming
See All in Programming
【CA.ai #3】Google ADKを活用したAI Agent開発と運用知見
harappa80
0
310
手が足りない!兼業データエンジニアに必要だったアーキテクチャと立ち回り
zinkosuke
0
700
20 years of Symfony, what's next?
fabpot
2
360
Canon EOS R50 V と R5 Mark II 購入でみえてきた最近のデジイチ VR180 事情、そして VR180 静止画に活路を見出すまで
karad
0
110
Building AI Agents with TypeScript #TSKaigiHokuriku
izumin5210
6
1.3k
ローターアクトEクラブ アメリカンナイト:川端 柚菜 氏(Japan O.K. ローターアクトEクラブ 会長):2720 Japan O.K. ロータリーEクラブ2025年12月1日卓話
2720japanoke
0
730
実は歴史的なアップデートだと思う AWS Interconnect - multicloud
maroon1st
0
150
Giselleで作るAI QAアシスタント 〜 Pull Requestレビューに継続的QAを
codenote
0
190
Why Kotlin? 電子カルテを Kotlin で開発する理由 / Why Kotlin? at Henry
agatan
2
7.2k
AIの誤りが許されない業務システムにおいて“信頼されるAI” を目指す / building-trusted-ai-systems
yuya4
6
3.6k
DevFest Android in Korea 2025 - 개발자 커뮤니티를 통해 얻는 가치
wisemuji
0
140
20251127_ぼっちのための懇親会対策会議
kokamoto01_metaps
2
430
Featured
See All Featured
YesSQL, Process and Tooling at Scale
rocio
174
15k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
Bootstrapping a Software Product
garrettdimon
PRO
307
120k
How to train your dragon (web standard)
notwaldorf
97
6.4k
Scaling GitHub
holman
464
140k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
390
Testing 201, or: Great Expectations
jmmastey
46
7.8k
The Illustrated Children's Guide to Kubernetes
chrisshort
51
51k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.4k
The Power of CSS Pseudo Elements
geoffreycrofte
80
6.1k
Mobile First: as difficult as doing things right
swwweet
225
10k
What's in a price? How to price your products and services
michaelherold
246
13k
Transcript
Automated Testing Lunch n Learn @incuna
What is it? • Unit tests • Integration tests •
Functional/acceptance tests • Visual tests • Regression tests
Why? • Trust in the code • Freedom to refactor
• Reduce number of bugs
What is it not? • A complete replacement for QA,
a useful tool for doing QA • For content
Types of test
Unit tests • Test small specific pieces of functionality •
Cover as many cases as possible • (Should be) quick and easy • Fragile but isolated • Mock out other layers • Coverage
Integration tests • Work across multiple layers of the program
• Ensure all the individual pieces fit together • Simulate real requests • Test only “normal” things • Should break less often
Functional or Acceptance tests • Test the whole system •
Test user stories • “Open up browser, go to home page, click on login link, fill in correct information, redirects to profile page, click on forum navigation, make a post, post appears on page...”
Functional or Acceptance tests • SLOW, and harder to write
• More likely part of the QA process than the development process • Immensely useful for front end logic
Visual tests • Does this page look like this screenshot?
• Cross browser • Needs research...
Regression testing
Regression tests • “AAAA this is broken we must fix
it now” • “I’ll write a test for it” • A bug is not a bug, it’s a missing test • Makes sure the bug doesn’t come back
Regression tests • Could be any one of the other
kinds of test • Never get written if the project didn’t have tests to start with
Continuous integration
Continuous integration • Runs test suite against changes and pull
requests • Warns us if someone breaks things • Runs in a production-like setting
Test driven development
Test driven development • Write the tests first • Add
code afterwards • (Refactor) • Check tests still pass • Repeat
Test driven development • Feels slower to start with •
More reliable than “refreshing the page to see if it worked” • Requires good tools • Saves time (and face) in the long run
Live demo time!