(Original) Test Driven Development (TDD) is getting popular these days. I had opportunity to being exposed it recently. I am not new to unit test. In the software company I worked for 8 years, we have regression test suites that runs automatically (at least daily), and we update the test suites as we find edge cases from customer bug reports, or in our development. That was about 8 years ago. Since the switch into Java land (2010), I started using JUnit and create/run the unit tests. One thing I was exposed to recently is Mocking in unit test, and TDD. Both takes a little time, and I am not fully bought into TDD yet. But I did learned something interesting on both topics lately, and like to share.
One of my coworker is very experienced and in-grained in this, as we are doing pair programming, I learned this a bit. An interesting back and forth as I was making changes to a method.
Coworker: “Do you have a test case?”
Me: test case for what?
Coworker: for the change?
Me: do we need this? …
But eventually we wrote the case, magically the web app also worked as soon as we passed the unit test. But overall I still have some reservation to do this, as I am not good at mocking e.g. Mockito, or writing test, and I think there is some cases pair programming can get the code right without go heavy in unit test.
Some links for mockito and spring test
2) Unit test (auto test suites)
I heard from my coworker recently that test suites should not use the implementation data source (database). I thought the main reason is the heavy weight/use from database resources point of view. But there is more, today I found if auto test consistently changes things on dev database, it’s really hard to find out the root cause, and cause confusion. Initially we thought the problem was caused by batch job, or the web app, spent a lot time trying to figure out, both are not the cause. And luckily, at the end we were able to find out the real cause.