I just watched a YouTube video today discussing where TDD went wrong, you can watch it if you want, but you don’t have to:
Basically, TDD has been around a while and has gone through a lot of analysis. Seems like most proponents now adays are talking about going back to the origins of TDD. That this methodology can lead to other struggles if not done properly. It was an interesting watch which for me makes me want to watch it again. I often watch things or read things multiple times to learn more, especially as I am trying to put it into practice.
What I got at the top level from this is that many people have gone down a difficult track by creating tests based around the classes and methods. There is a concept of testing around “Modules” which seems more related to the idea of the application architecture in terms of the intended user of the application or system. Testing that will always be helpful and the test will not have to change if you change how you’ve implemented the solution.
In terms of this Form Auditor, I am thinking perhaps I am trying to test at too granular a level, but really I HAVE NO IDEA WHAT I’M DOING. I’m just starting this foray into TDD. I haven’t really done it before and certainly not professionally, so just letting you know: Beware using this series as a training guide. It’s really more a journey I’m taking and you are tagging along.
Feel free again to shoot me an email reply to this and let me know what you think.
I see that I am currently in a passing test mode, so I can refactor if I want. One thing I don’t think i’ve done yet which would be helpful is to get a better naming convention for my test. Here is my current list of test names:
![](https://www.accessjumpstart.com/wp-content/uploads/2024/01/image.png)
I’m thinking that I’ve heard of a method of naming using the “Given-When-Then” pattern.
- IterateWhenNothingChangedReturnsEmptyDictionary -> GivenFormIteratorWhenNothingChangesReturnEmptyDictionary
- FormListenerRaisesBoundDataChangedEvent -> WAIT!
Uh-oh, just realized as I was looking at the code that I am not supposed to be in a non-failing test cycle. I had not finished writing the test for FormListenerRaisesBoundDataChangedEvent. So I have added an Assert.Inconclusive to the end so my tests now look like this:
![](https://www.accessjumpstart.com/wp-content/uploads/2024/01/image-1.png)
So I guess my next step will be to at least get that test to pass before I do anything else.
Join me next time! See you tomorrow!