Artwork

Innhold levert av iteration podcast, John Jacob, and JP Sio - Web Developers. Alt podcastinnhold, inkludert episoder, grafikk og podcastbeskrivelser, lastes opp og leveres direkte av iteration podcast, John Jacob, and JP Sio - Web Developers eller deres podcastplattformpartner. Hvis du tror at noen bruker det opphavsrettsbeskyttede verket ditt uten din tillatelse, kan du følge prosessen skissert her https://no.player.fm/legal.
Player FM - Podcast-app
Gå frakoblet med Player FM -appen!

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

32:27
 
Del
 

Manage episode 227545522 series 1900125
Innhold levert av iteration podcast, John Jacob, and JP Sio - Web Developers. Alt podcastinnhold, inkludert episoder, grafikk og podcastbeskrivelser, lastes opp og leveres direkte av iteration podcast, John Jacob, and JP Sio - Web Developers eller deres podcastplattformpartner. Hvis du tror at noen bruker det opphavsrettsbeskyttede verket ditt uten din tillatelse, kan du følge prosessen skissert her https://no.player.fm/legal.

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 episoder

Artwork

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

iteration

113 subscribers

published

iconDel
 
Manage episode 227545522 series 1900125
Innhold levert av iteration podcast, John Jacob, and JP Sio - Web Developers. Alt podcastinnhold, inkludert episoder, grafikk og podcastbeskrivelser, lastes opp og leveres direkte av iteration podcast, John Jacob, and JP Sio - Web Developers eller deres podcastplattformpartner. Hvis du tror at noen bruker det opphavsrettsbeskyttede verket ditt uten din tillatelse, kan du følge prosessen skissert her https://no.player.fm/legal.

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 episoder

Todos los episodios

×
 
Loading …

Velkommen til Player FM!

Player FM scanner netter for høykvalitets podcaster som du kan nyte nå. Det er den beste podcastappen og fungerer på Android, iPhone og internett. Registrer deg for å synkronisere abonnement på flere enheter.

 

Hurtigreferanseguide

Copyright 2024 | Sitemap | Personvern | Vilkår for bruk | | opphavsrett