Test Driven Xamarin Development

Play Test Driven Xamarin Development
Sign in to queue

The Discussion

  • User profile image
    Dave Schinkel

    Decent talk, thank you for promoting that in the .NET community more.

    But disagree on a few things that most TDD'ists would argue against:

    1 assert per test - I don't agree. I used to think the same thing when I started TDDing 3 years ago. Primiarly got that from Roy Osherove. However I came to learn by pairing with others who have TDD'd for a long time, that when you test a "unit" of something, it may take 1-3 asserts or so to assert that that "unit" works. That's something a lot of people think you should do, and that's simply not a rule you should follow or feel you must follow 100% of the time. Any TDD'st who has been around, you'll definitely not see them do only one assert per test always. In fact half the time you do, half the time you don't.

    The cop - well, those aren't too stringent. Those are principals to follow that are part of the core of what makes TDD work. If you start to lax on those 3, you're moving away from TDD. I don't find it funny when people on the .NET side say that, I hear that a lot in the .NET world for some reason. This isn't about being perfect, it's about following guidelines that have been proven to work by Kent Beck


    BDD isn't "something the cool kids are doing" - you talk as if it's some kind of fad. BDD is the evolution of TDD. Over the years, TDD'ists found that if you just start with TDD and not being guided by business requirements (stories), and by not starting with BDD acceptance tests, you run the risk of:

    1) Not knowing when you're truly "done" with a story
    2) over-testing - you're now trying to test in the mindset of classes and methods rather than the "contract"
    3) Not knowing how to start or what tests to start with. BDD helps guide you as a developer

    TDD is a subset of BDD. BDD is critical these days where you can do BDD...especially if you're test driving the creation of web application or mobile app features. I even use it for driving my Web Service Contract design and use lower-level TDD tests to implement the behavior.

Add Your 2 Cents