First Pass Completed: Rough Draft TDD Demonstration Videos 131
As promised, I’ve made a complete sweep through a series of videos. You can find all of them: here.
These videos include several warts and false starts. Depending on the interest and feedback, I’ll redo these at some point in the future.
Question: Should I repeat this series in C#, or some other language? Some people have expressed interest in this. It’s probably 15 hours of work in C#, so I’d need to know it was worth the effort. What’s your opinion on that?
- Getting Started
- Adding Basic Operators
- Removing Duplication
- Extracting to Strategy
- Removing Duplication via Refactoring or Removing Duplication via Tdd using Mockito
- Introducing an Abstract Factory
- Adding a Sum operator
- Adding Prime Factors Operator
- Composing Operators and Programming the Calculator
- Using FitNesse to Program the Calculator
I’ve already received several comments both here on the blog as well as with the videos. I’ll keep track of those comments and incorporate the ones that fit for me.
Each video has a link on its page to download it. However, to download a video, you will have to create an account and log in. So here are the links, these won’t work without first creating an account (I’ll update original blog with these as well):- Getting Started Download
- Adding Basic Ops Download
- Removing Duplication Download
- Extracting to Strategy
- Removing Dups/Refactoring Download
- Removing Dups/Tdd Download
- Abstract Factory Download
- Sum Operator Download
- Prime Factors Download
- Composing Math Operators Download
- Using FitNesse Download
Infinitest for Java, have you tried it? 10
Background
About 2 years ago, I was working with Ben Rady and he demonstrated something he was working on at the time: Infinitest. As often I am, I was a little interested but mostly skeptical – don’t know if that came across or not.Since then he and others (e.g., Rod Coffin have made amazing strides and created plugins for both Eclipse and IntelliJ.
Taking it for a test run
Earlier this month, I finally decided to give it a test drive. When I made that announcement, Ben made the following (bold?) statement:For me, using Infinitest is as different from TDD as TDD is from not testing
So is that true? Is using a continuous test execution tool as different from not using one as using TDD is from not testing? I’m not sure I’m there yet. However, I will say my brain is having some difficulty getting used to the cool feedback.
Here are two recent experiences I had using it.
Classpath Issues
Back at the end of 2006 I wrote a class on using JPA and EJB 3. I’ve not really done much to update that material in some years but recently I had an email from someone trying to work through the first tutorial with little success. Over the past few years there’s been some bit-rot. The embeddable container is not really up to date, EJB 3.1 includes an embeddable container as part of its spec, Hibernate has been updated, etc. So I spent a few hours tracking down updated jar files and building my classpath. I had already installed Infinitest and I noticed as added I something to my classpath, Infinitest would kick off and show a stack trace (my code was doing that in a @Before method). So I sped up what I was doing:- I directly edited the .classpath file in Eclipse
- Saved what I was doing
- Waited about a second
- Noticed the new stack trace
- Found the next jar file I needed to add
- Repeat until tests passed.
Might sound like a bit of overkill, but in the end I built a classpath from scratch and I ended up adding 13 jar files. So it saved some time.
Note, I wasn’t looking for this. I had only installed Infinitest the day before so this was unexpected and welcome! Oh, and before my @Before method was handling the exception properly, Infinitest showed that the code had a problem (it was in the @After with a null pointer exception), which it indicated as an error like a syntax error or a validation error. Nice!
Using Mockito
I’ve recently been using Mockito. You can review a previous blog entry for that example. Today we’re holding the first coding dojo at the recently opened OkC CoCo. Last night I started working on the next problem I want to use for the next dojo. It involves practicing using a mockist approach. I set up my classpath, started writing tests and immediately I noticed what looked like a syntax error on the verification step of my first unit test. I was confused thinking I had an actual syntax error since I’m not quite to the point of touch-typing Mockito based tests (I did update Eclipse so I could more easily find the static imports).Next, I updated my test to use the @Mock annotation. I removed the hand-written initialization and immediately I noticed a “syntax” error – null pointer exception. I was immediately (OK 1 second later) showed the impact of removing a single line of code. I added the missing line to auto-initialize the @Mock annotated fields but I did it incorrectly, so the error remained. I finally got the line correct and the “syntax error” went away.
Observations
Wow. That’s what I have to say so far. I’m not entirely sure the before and after of using Infinitest is the same size as moving from not testing to using TDD. Maybe it’s the same as moving from being Test Infected to practicing TDD. I was Test Infected several years before I practiced TDD.I was also about as skeptical that moving to TDD from being Test Infected was useful. I was wrong. History tends to repeat itself, so I’m guessing, based on my initial resistance, that this is the future.
Embrace it.
Mockito Example (Java Mocking Framework) 125
Recently I was lamenting how much I liked Moq for C# and its API. I like that is uses lambdas and generics and I think both the interface and general approach are great.
Someone I follow on twitter, @tieTYT, suggested that I should give Mockito a try. It is a mocking library for Java, written by Szczepan Faber and friends.
Well I gave it a try and I found it to be an excellent Mocking framework similar in spirit to Moq and it worked well while not requiring lambdas.
I was in a mood, so I went ahead and wrote a quick tutorial. While it is still under construction, you can have a look at it. If you work through it, you’ll:- Develop something using TDD.
- Using a mockist approach
- Use Inversion of Control
- Refactor code to use the GoF state pattern
- Refactor code to use the GoF Template Method Pattern
- Fix the code to avoid violation of the Liskov substitution principle (this is in there though not currently emphasized)
- Fix the code to avoid violation of the Dependency Inversion Principle.
- And as a side benefit, by using a TDD approach you’ll naturally avoid violating the Law of Demeter (though you will introduce some feature envy).
Have fun and please comment. You can also view a printable version.
FWIW, I learned Mockito and wrote this tutorial in about a single work day, so it was pretty easy to pick up and use. I suspect my recent experience with Moq gave me the mental model and then it was just a matter of syntax.