• Testing & ALM

    30 Days of TDD – Day 24 – Strictly Mocking

    November 25, 2013 Share
    As I mentioned in my previous post, TDD is easy to do in a green field situation. However for most developers these types of projects are few and far between. Sometimes the brown field project we’re working on don’t lend themselves to unit testing. In the last post I demonstrated how Future Mocking can help in situations where mocking is difficult due to the use of statically bound dependencies. In this post I’ll show how using strict mocking can help ensure that you’re “after the fact” mocks of dependencies and methods are in line with how these components actually work.

  • Testing & ALM

    30 Days of TDD – Day 23 – Mocking… FROM THE FUTURE!

    November 20, 2013 Share
    The examples I’ve been working with for this series have assumed that you are doing "Green Field” development. This means that we are writing an application from scratch and can make sure all of the things that make code testable are incorporated into our design from the start. The biggest one of these things being the user of dependency injection. But what if you are working on “legacy” code that still uses static dependencies and not dependency injection? Is TDD and unit testing out of reach due to a decision made at the beginning of the project? Not necessarily.
  • Testing & ALM

    30 Days of TDD – Day 22 – When is a Test Not a Unit Test?

    November 15, 2013 Share
    The focus of this series has been Test Driven Development. TDD relies on unit tests, and so the focus of this series has been on unit testing. And just to make sure I’m clear; your unit tests, and the practice of letting them drive your development are VERY important! But the truth is that unit testing is not the only kind of testing that you should be thinking about.

  • Testing & ALM

    30 Days of TDD – Day 21 – A Tale of Two Defects

    November 13, 2013 Share
    Test Driven Development changes the way you approach development of new features in your application. But it doesn’t stop there. Good TDD practice extends to the way you deal with all features and code you add to your application. In this post you’ll see how the practices of TDD extend to defects and demonstrates that your tests are part of your code and why it’s important to pay attention to their quality as well.
  • Testing & ALM

    30 Days of TDD – Day 20 – Refactoring Revisited Pt. 3

    November 11, 2013 Share
    In the previous post we started refactoring our code to make sure we were complying with the SRP. Using our tests we are able to optimize our code for readability and maintainability. We’ll continue in the post by examining how the interactions between the code we want to extract to methods needs to be taken into account when refactoring.