Test-Driven Development
Test-Driven Development is a technical practice that supports Agile's iterative and incremental development cycle. TDD helps you quickly discover mistakes, preventing defects. You weave a test safety net as you grow your product's behavior one test at a time. This safety net supports you now and in the future to help you keep code working as you change it. Oh yeah, don't let me forget to tell you it's fun and once you learn it, you save time and money.
Maybe you have heard of Test-Driven Development but don't quite get it. A good way to understand TDD is to pair program with an experienced practitioner. We will start with a brief overview and demo of Test-Driven Development. In this interactive workshop, you can practice TDD in C. You don't need to install any tools for this workshop. You'll run the exercise on my exercise server. You will know what TDD is after this session. We'll conclude the workshop with a debrief on your experience.
Before attending this workshop, it is highly recommended that you watch this talk from the 2020 Embedded Online Conference.
Why does James Grenning write a failing test before implementing behavior in Test-Driven Development?
Hello Marko
I am so sorry I missed this. I gues I am not notified when there are questions. Please reach out to me if you have other questions on my website
wingman-sw.com
The time spend proactively test-driving code, rather than reactively debugging is in TDD's favor, once you learn it. Now, believing me is another thing. Pretty much you need to convince yourself by trying TDD. My EOC workshops is a start and my courses can help you get the feel of TDD and start to see its power.
The small steps are very non-intuitive and one of the underpinnings of TDD. What size steps do you work in when you are debugging? You work in small steps debugging because you have to. You inspect each minute detail to see what you got wrong.
Why do we work in small steps during debugging? I'll answer: Because we are only good at solving one problem at a time. The small steps of TDD show we accept this limitation, and help you work within your limits.
You'll also see that TDD influences design, leading you to separate unit-testable code from code needed integration tests (HW or environment-dependent code).
Hello James,
I have one question for you that I was not able to ask in the workshop.
I work in a IoT company as an embedded programmer, we manly write code for Zephyr and NRF5 SDK based products. We are usually dealing with trackers and systems that have BLE, LoRa, LTE, GPS connectivity, plus usually tons of sensors.
With my coworkers we were watching your last years talk. Our major concern is that faking (through the mocks) all the connectivity part of the products would be slow and would add an overhead which would put us behind in the deadlines. Plus they did not like the steps of the mini test cycle, which I can understand as they could not see the full benefit from ouor short presentation. Can you give some thoughts on mocking hardware and networking depended parts of the ssystems?