<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Machine-Cycle</title>
    <link>https://machine-cycle.pages.dev/en/</link>
    <description>Recent content on Machine-Cycle</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Sun, 29 Aug 2021 10:00:00 +0200</lastBuildDate><atom:link href="https://machine-cycle.pages.dev/en/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Integration test with Pulumi and Azure Kubernetes Service</title>
      <link>https://machine-cycle.pages.dev/en/posts/integration_test_pulumi/</link>
      <pubDate>Sun, 29 Aug 2021 10:00:00 +0200</pubDate>
      
      <guid>https://machine-cycle.pages.dev/en/posts/integration_test_pulumi/</guid>
      <description>Let&amp;rsquo;s see how to use Infrastructure as Code for the provisioning and the testing in an integration environment We are carrying out update activities on some products for one of our clients, gradually migrating to microservice architectures. One of these products has followed the policy of “do not touch what works” for a long time, and as a result, it becomes unmanageable over time. Some classes representing business logic have grown beyond measure, becoming very complex to modify, with insufficient test coverage and a business logic shared between the various domains that coexist in the same codebase.</description>
    </item>
    
    <item>
      <title>A different way of thinking about testing: the Property Based Test</title>
      <link>https://machine-cycle.pages.dev/en/posts/property_based_testing/</link>
      <pubDate>Thu, 29 Jul 2021 10:00:00 +0200</pubDate>
      
      <guid>https://machine-cycle.pages.dev/en/posts/property_based_testing/</guid>
      <description>Let’s see why a coverage of 100% is not enough to make us sleep safe and sound In my previous article, we have seen how testing and refactorizing legacy code with Golden Master Pattern. Now, we will continue to talk about testing, introducing a new paradigm with a simple example.
We are familiar with writing tests based on examples. In literature we talk about “Example test”: given an input we have an expected output.</description>
    </item>
    
    <item>
      <title>Golden Master Pattern: don’t fear the legacy code!</title>
      <link>https://machine-cycle.pages.dev/en/posts/golden_master/</link>
      <pubDate>Wed, 29 Jul 2020 10:00:00 +0200</pubDate>
      
      <guid>https://machine-cycle.pages.dev/en/posts/golden_master/</guid>
      <description>Let’s see together how to modify legacy code ensuring it works thanks to the Golden Master Pattern Anyone who works in the software development world will have had the need to add features on the legacy code, perhaps inherited from the previous team, and on which you need to make an urgent fix.
Many definitions of legacy code can be found in literature, the one that I prefer is: “By Legacy code, we mean the profitable code that we feel afraid to change”.</description>
    </item>
    
  </channel>
</rss>
