Artwork

Sisällön tarjoaa iteration podcast, John Jacob, and JP Sio - Web Developers. iteration podcast, John Jacob, and JP Sio - Web Developers tai sen podcast-alustan kumppani lataa ja toimittaa kaiken podcast-sisällön, mukaan lukien jaksot, grafiikat ja podcast-kuvaukset. Jos uskot jonkun käyttävän tekijänoikeudella suojattua teostasi ilman lupaasi, voit seurata tässä https://fi.player.fm/legal kuvattua prosessia.
Player FM - Podcast-sovellus
Siirry offline-tilaan Player FM avulla!

Testing... Testing... 123...

32:27
 
Jaa
 

Manage episode 227545522 series 1900125
Sisällön tarjoaa iteration podcast, John Jacob, and JP Sio - Web Developers. iteration podcast, John Jacob, and JP Sio - Web Developers tai sen podcast-alustan kumppani lataa ja toimittaa kaiken podcast-sisällön, mukaan lukien jaksot, grafiikat ja podcast-kuvaukset. Jos uskot jonkun käyttävän tekijänoikeudella suojattua teostasi ilman lupaasi, voit seurata tässä https://fi.player.fm/legal kuvattua prosessia.

Iteration S05E09

Testing… Testing… 123

Publishing February 18th - Hope everyone had a good Valentine’s Day weekend!

A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter.

Introduction

  • Writing changeable code is an art on which practice relies on three different skills. First, you must understand object-oriented design. Poorly designed code is naturally difficult to change.
  • First, you must understand object-oriented design. A poorly designed code is naturally difficult to change.
  • Second, you must be skilled at refactoring code.
  • Finally, the art of writing a changeable code requires the ability to write high-value tests. Tests give you the confidence to refactor constantly.

Reasons to test:

  • Finding Bugs
  • Supplying Documentation
  • Deferring Design Decisions
  • Supporting Abstractions
  • Exposing Design Flaws

Knowing What to test:

  • “Most developers write too many tests” - OR NONE! hahaha
  • Tests should concentrate on the incoming or outgoing messages that cross an object’s boundaries.
  • Back to the Kitchen Metaphor - Test that ordering a hamburger, returns a hamburger as expected, not that the kitchen staff turns on the grill or slices tomatoes.
  • Incoming messages should be tested for the state they return.
  • Outgoing command messages should be tested to ensure they get sent.
  • Outgoing query messages should not be tested.

Knowing When to Test

  • Write tests first, whenever it makes sense to do so

Knowing How to test:

  • Testing Styles: Test Driven Development (TDD) and Behavior Driven Development (BDD).
  • Proving the Public Interface
  • Injecting Dependencies as Roles
  • Testing Inheritance - Test your base class - then include the module to test each of the responses that are in the base class.
  • Creating Test Doubles - DiameterDouble - A test double is a stylized instance of a role player that is used exclusively for testing - tend to override the base class in my test helper - I’ve run into silent errors this way.
  • Testing Private Methods - interface. These private messages are like proverbial trees falling in empty forests; they do not exist, in a perfect world they do not need to be tested - testing them is a code smell.
  • Testing Ducks - create a preferred test interface - mechanic and a guide can both prepare - you can establish a single interface and simply pass the different objects into it.
  • Testing Inherited Code
  • Testing Models + Objects Vs interface - where’s the balance?

Tests are indispensable. Well-designed applications are highly abstract and under constant pressure to evolve; without tests these applications can neither be understood nor safely changed. The best tests are loosely coupled to the underlying code and test everything once and in the proper place. They add value without increasing costs.

Next Episode - Recap of Practical Object-Oriented Design and New book announcement!

Picks:

NOUN PROJECT - https://thenounproject.com/

**Super Smash Bros Ultimate **

Neil Davis - @Nei1dor

Aaron Kelton

  continue reading

78 jaksoa

Artwork

Testing... Testing... 123...

iteration

113 subscribers

published

iconJaa
 
Manage episode 227545522 series 1900125
Sisällön tarjoaa iteration podcast, John Jacob, and JP Sio - Web Developers. iteration podcast, John Jacob, and JP Sio - Web Developers tai sen podcast-alustan kumppani lataa ja toimittaa kaiken podcast-sisällön, mukaan lukien jaksot, grafiikat ja podcast-kuvaukset. Jos uskot jonkun käyttävän tekijänoikeudella suojattua teostasi ilman lupaasi, voit seurata tässä https://fi.player.fm/legal kuvattua prosessia.

Iteration S05E09

Testing… Testing… 123

Publishing February 18th - Hope everyone had a good Valentine’s Day weekend!

A weekly podcast about programming, development, and design through the lens of amazing books, chapter-by-chapter.

Introduction

  • Writing changeable code is an art on which practice relies on three different skills. First, you must understand object-oriented design. Poorly designed code is naturally difficult to change.
  • First, you must understand object-oriented design. A poorly designed code is naturally difficult to change.
  • Second, you must be skilled at refactoring code.
  • Finally, the art of writing a changeable code requires the ability to write high-value tests. Tests give you the confidence to refactor constantly.

Reasons to test:

  • Finding Bugs
  • Supplying Documentation
  • Deferring Design Decisions
  • Supporting Abstractions
  • Exposing Design Flaws

Knowing What to test:

  • “Most developers write too many tests” - OR NONE! hahaha
  • Tests should concentrate on the incoming or outgoing messages that cross an object’s boundaries.
  • Back to the Kitchen Metaphor - Test that ordering a hamburger, returns a hamburger as expected, not that the kitchen staff turns on the grill or slices tomatoes.
  • Incoming messages should be tested for the state they return.
  • Outgoing command messages should be tested to ensure they get sent.
  • Outgoing query messages should not be tested.

Knowing When to Test

  • Write tests first, whenever it makes sense to do so

Knowing How to test:

  • Testing Styles: Test Driven Development (TDD) and Behavior Driven Development (BDD).
  • Proving the Public Interface
  • Injecting Dependencies as Roles
  • Testing Inheritance - Test your base class - then include the module to test each of the responses that are in the base class.
  • Creating Test Doubles - DiameterDouble - A test double is a stylized instance of a role player that is used exclusively for testing - tend to override the base class in my test helper - I’ve run into silent errors this way.
  • Testing Private Methods - interface. These private messages are like proverbial trees falling in empty forests; they do not exist, in a perfect world they do not need to be tested - testing them is a code smell.
  • Testing Ducks - create a preferred test interface - mechanic and a guide can both prepare - you can establish a single interface and simply pass the different objects into it.
  • Testing Inherited Code
  • Testing Models + Objects Vs interface - where’s the balance?

Tests are indispensable. Well-designed applications are highly abstract and under constant pressure to evolve; without tests these applications can neither be understood nor safely changed. The best tests are loosely coupled to the underlying code and test everything once and in the proper place. They add value without increasing costs.

Next Episode - Recap of Practical Object-Oriented Design and New book announcement!

Picks:

NOUN PROJECT - https://thenounproject.com/

**Super Smash Bros Ultimate **

Neil Davis - @Nei1dor

Aaron Kelton

  continue reading

78 jaksoa

Alla avsnitt

×
 
Loading …

Tervetuloa Player FM:n!

Player FM skannaa verkkoa löytääkseen korkealaatuisia podcasteja, joista voit nauttia juuri nyt. Se on paras podcast-sovellus ja toimii Androidilla, iPhonela, ja verkossa. Rekisteröidy sykronoidaksesi tilaukset laitteiden välillä.

 

Pikakäyttöopas