<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>TDD on Dhaval Shah</title><link>https://www.dhaval-shah.com/tags/tdd/</link><description>Recent content in TDD on Dhaval Shah</description><generator>Hugo -- gohugo.io</generator><lastBuildDate>Sun, 11 Mar 2018 14:28:47 +0000</lastBuildDate><atom:link href="https://www.dhaval-shah.com/tags/tdd/index.xml" rel="self" type="application/rss+xml"/><item><title>Bootiful Test Driven Development</title><link>https://www.dhaval-shah.com/bootiful-test-driven-development/</link><pubDate>Sun, 11 Mar 2018 14:28:47 +0000</pubDate><guid>https://www.dhaval-shah.com/bootiful-test-driven-development/</guid><description>Software engineers have been ardently following Test Driven Development (TDD) as an XP practice for having necessary safety nets. I have even tried covering different schools of TDD with an example in one of my previous posts. Considering recent surge in using Spring Boot for developing Microservice applications, I felt a need to understand and learn how to do TDD whilst implementing Spring Boot application.
In order to understand how Spring Boot simplifies the overall process of doing TDD, we will consider a very simple use case -</description></item><item><title>Microservices and Consumer Driven Contract testing using Pact</title><link>https://www.dhaval-shah.com/microservices-and-consumer-driven-contract-testing-using-pact/</link><pubDate>Mon, 10 Jul 2017 20:37:52 +0000</pubDate><guid>https://www.dhaval-shah.com/microservices-and-consumer-driven-contract-testing-using-pact/</guid><description>Background As per the current trends, Microservice Architecture has become a common paradigm using which enterprise applications are built. With this paradigm shift, an application is going to have myriad set of independent and autonomous (micro)services. So how does a developer do testing within Microservice Architecture? Answer is very obvious -
Create integration tests that invokes microservice under test which will internally call dependent microservices Get all the services under test up and running Start executing integration test which invokes microservice under test With this approach, the entire developer level integration testing will have following disadvantages -</description></item><item><title>Anatomy of Test Driven Development – Part 2</title><link>https://www.dhaval-shah.com/anatomy-of-test-driven-development-part-2/</link><pubDate>Mon, 16 Jan 2017 18:14:52 +0000</pubDate><guid>https://www.dhaval-shah.com/anatomy-of-test-driven-development-part-2/</guid><description>This is the concluding blog of 2 part series on 'Anatomy of Test Driven Development'. Continuing from where we left in first part of this series, this will mainly talk about 'How' part of TDD along with its avatars.
How to do TDD
We start with a Test. To get this to work we need to frame the test. We need to make sure that there is enough code in place to make it compile or to make it to work and not throw up run time error.</description></item><item><title>Anatomy of Test Driven Development – Part 1</title><link>https://www.dhaval-shah.com/anatomy-of-test-driven-development-part-1/</link><pubDate>Thu, 05 Jan 2017 19:48:47 +0000</pubDate><guid>https://www.dhaval-shah.com/anatomy-of-test-driven-development-part-1/</guid><description>Since we being one of the most intellectual and so called logical species on this earth, we need proper rationale behind each and every action that we do in our personal and professional life. Hence I thought to pen down a two post series highlighting rationale behind following one off the most important and underrated XP practice of software devlopment i.e. Test Driven Development
What is TDD Lets try to understand definition of TDD and the primary motive behind TDD; this was outlined by none other than one of the protagonist of TDD i.</description></item></channel></rss>