<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>PBT on Machine-Cycle</title>
    <link>https://machine-cycle.pages.dev/tags/pbt/</link>
    <description>Recent content in PBT on Machine-Cycle</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>it</language>
    <lastBuildDate>Thu, 29 Jul 2021 10:00:00 +0200</lastBuildDate><atom:link href="https://machine-cycle.pages.dev/tags/pbt/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Un modo diverso di pensare al testing: Property Based Test</title>
      <link>https://machine-cycle.pages.dev/posts/property_based_testing/</link>
      <pubDate>Thu, 29 Jul 2021 10:00:00 +0200</pubDate>
      
      <guid>https://machine-cycle.pages.dev/posts/property_based_testing/</guid>
      <description>Vediamo insieme perché un coverage del 100% non basta a farci dormire tranquilli Nel mio precedente articolo, abbiamo visto come testare e rifattorizzare un progetto legacy utilizzando il Golden Master Pattern. Stavolta, continueremo a parlare di testing, introducendo un nuovo paradigma attraverso un semplice esempio.
Siamo abituati a scrivere test basandoli su esempi. In letteratura si parla di “Example test“: dato un input abbiamo un output atteso.
La diffusione di tecniche come il TDD e la crescente importanza assunta in generale dai test nella realizzazione di un prodotto software rischiano di creare un grosso fraintendimento, ossia che una buona suite di test è tale se massimizza la coverage.</description>
    </item>
    
  </channel>
</rss>
