Home > On-Demand Archives > Q&A Sessions >
Live Q&A - Iterative Development: XP, Test-Driven Development and Refactoring
James Grenning - Watch Now - Duration: 27:31
Hi Michele
The short answer: write a test :-)
A longer answer: There is a step-by-step approach to getting existing code into a test environment. The recipe is here https://wingman-sw.com/articles/tdd-legacy-c. You could also buy my book to get an understanding of what TDD is.
Final answer: My training TDD training course has helped thousands of engineers start using TDD. It walks you through TDD, so you can experience it and get your questions answered. I offer live and self-paced versions of the course. See https://wingman-sw.com/
Hi James,
thank you very much for your answer. It's hard to change people mindset. I already set up years ago a unit test environment but people don't like to use it. Thanks a lot. I followed also the speach you did last year, very interesting.
I used to think people would see TDD and want it. I forgot it took expert guidance and personal experience for me to realize its value. When you add tests after development, it feels like extra work. That is especially true when people first manually test, then add tests that pass right away. TDD does not have that feel. It turns programming into a flowing process, at least at times.
Engineers don't want to change unless they know what problem they are trying to solve. In my training, I start with the mind-opening process by describing defect prevention with TDD. Then people see and try TDD. After their first experience, everyone has concerns, usually about time or figuring out what tests to write. At this point in the mind-opening process, we can discuss the concerns and I can give the perspective of an experienced TDDer. I find this helps people potential benefits and they are more open to learning more and trying it.
Monday's alpha-geek skeptics, become Thursday's coaches.
The front page of my website has two intro videos: TDD Why? and What is it?
https://wingman-sw.com/
Very entertaining!
I took an intro class on TDD some years back. The thing that stood out in my mind most is, if you can, try to incorporate the TDD tests you develop into system start up. This will catch refactoring errors or system level changes immediately. The only drawback is that boot up time will take longer.
The boot time is not too long. When I first learned of TDD, it was only about a month before we were ahead of the game. Legacy code makes it more of a challenge but still provides important safety when changing existing code.
Very engaging presentation! I am a believer in tests, but struggle writing them on small embedded control systems. For example an input goes high and a specified output must go high for a specified period of time. Do you have references or suggestions on writing test for such hardware coupled designs? Thanks!
To really answer this, I would have to ask some followup questions. Because, like most good questions in software development... it depends.
How do you do timing? with a delay loop or a timer? Delay loop makes it easy. Time means you need to fake out time. I cover this in my book.
Here are a couple articles about testing a legacy driver and test-driving a driver.
https://blog.wingman-sw.com/test-legacy-device-driver
https://blog.wingman-sw.com/tdd-flash-driver
Thank you for your answer to my question in the live Q&A. I have a bit of a follow up:
Test Driving small simple components gives confidence in those components. How do you gain confidence that they work when integrated together?
To gain confidence that the integrated system works, you you can add integration and system tests. Take a look at the testing pyramid. This is probably a good article on the topic. https://martinfowler.com/articles/practical-test-pyramid.html
You'll need your imagination to expand the idea to cover embedded. In a way all software has the same problem, dependency. Embedded code often has hardware dependencies. A web app may have database dependencies. The techniques to solve the dependency are the same.
Thanks for another good presentation. As my prevoius poster mentioned, hard to stop laughing. Do you sell the your shirts :-)
On the other hand it's terrible how often you come to a project as the firefighter you should never have been!
I'm a programmer and I write bugs.
But I'm doing it not only once, I do it 5 to six times. Just to be sure .... ;-)
Thanks!
I found the t-shirt online somewhere. I probably searched for "funny programmer t-shirts".
There are a lot of good ones for people open to laughing at themselves.
Hi James... Amazing talk... I liked the focus or your presentation... I enjoyed... I have some questions:
-
How I can start a new project focus on TDD using a RTOS?
-
How can include TDD in a current RTOS project?
I recommend that you first get tests running off-target, for things that can run off-target. Then you can test anywhere, and it does encourage you to improve your design for portability and hardware independence.
If your target is constrained, you'll want to find a small-footprint test harness (cmocka, unity/ceedling). If your target is not constrained, you could use CppUTest (I am one of the authors). Several people have ports for CppUTest and the google group are helpful.
Both questions have the same answer. Start with a "hello, world" executable, build a simple test checking the functionality of the test harness. For example: watch CHECK(true) pass and watch CHECK(false) fail. Start growing your first test.
Once you have a test-runner, check out my article on getting legacy C into a test environment.
https://wingman-sw.com/articles/tdd-legacy-c
Amazing James... Thanks for your response... It will change the way that I develop embedded code... Thank very much
Another developer and I are refactoring a Proof-of-Concept crypto library we inherited from someone else who cobbled it together over the last 6 years. When we started, I said, "I think TDD is the way to go," and I showed him your book and how to get going with Unity & Ceedling. I got his buy-in and after 2 months of work with even a basic understanding, it's become an indispensable part of our development. It's helped find flaws in the design by reshaping our thinking about the form and behavior of components/modules/whatever. With our own experience and access to this video, I think it'll be even easier to win over the others on our team who have been on the fence!
Hi Jeremyo
Great to hear that you got value from TDD so quickly. That was my experience as well.
Cheers, James
I collect TDD stories from the field. Let me know if you want to write a few paragraphs about your experience. See https://wingman-sw.com/stories and use my contact form to reach me about it.
Thanks James for another great presentation. This video has a number of topics that brings to light on TDD, Refactoring, etc. and other software engineering topics to embedded development.
I could not stop laughing!
Debugging: Being the detective in a movie where you are also the murderer
Programmer: Someone who solves a problem you didn't know you had in a way you don't understand
This was an awesome presentation!
By the way, I am a programmer and I write bugs.
Very good content.
Thank you.
Thanks for watching!
You can use my contact form to get the training coupon.
https://wingman-sw.com/contact-us
Select "Test-Driven Development Training - Self-paced".
Hello..
I was wondering how do we get the tdd training coupon??
15:31:32 From Keith J : Unsolicited advertisement for James - If you want to learn more about TDD, his class is really good. 15:44:31 From Cole Wyant : What are some ways to unit test modules use opaque data types? For example, I developed a module to monitor temperature that used a state machine. Most of my tests would verify that given a certain condition, the state machine jumped to the proper state. I kind of cheated and used macros to expose the private members of the state machine during testing. Is there a better way to test modules with opaque data? 15:49:07 From Brian Cabebe : Suggestion for Gillian, lead by example. Can you use TDD on the code you work on? 15:50:40 From Gillian Minnehan : @Brian I am using it! In my upcoming merge request, I have a lot of great unit tests that I'm hoping they notice 15:51:21 From Jacob Beningo : ? 15:58:07 From Ross : I've found the Active Object design pattern helps eliminate lots of mocks from my testing. 15:58:46 From Geoff : thanks, i'll check it out 15:58:49 From Gillian Minnehan : Thank you!
Hello James, thanks a lot for the interesting presentation. What about exiting projects? Do you have reccomendations to move step by step to a TDD approach?
thanks
Michele