Re: Getting back into C# testing

It will definitely hurt less if you wrap the API, because then you can test
your own code in isolation from it where it makes sense to do so. As far as
tools go, ReSharper, NUnit, and SpecFlow are my favorites for test-driving
C#, but it would probably be worth spending time researching what else is
out there.


On Fri, Sep 5, 2014 at 8:41 AM, Alan Baljeu [email protected]
[testdrivendevelopment] <[email protected]> wrote:

>
>
> I've been away from serious OOP programming for a while, working in
> Prolog, etc.  So now I'm back, using VS2013, and starting development
> with a large CAD API.
>
> My TDD experience has followed the old data-oriented style, testing
> whether a function causes the right kinds of objects to be produced, rather
> than testing that it invokes the right methods.  (It makes more sense to
> me, that my concern is to construct the correct and very visible model, and
> not how that model was constructed.)
>
> So now, given this brand-new API (which I know is well made and stable),
> is it a good idea to create my own classes to wrap access to the API, or is
> it better just to access the API directly?
>
> Following the TDD mantra of test-first, I'm thinking about:
> {
>   setup the test scenario.
>   do something interesting.
>   check what happened.
> }
>
> I write the above in natural fashion, and then build classes and methods
> to match that fashion, and link those to the underlying API.
>
> Does this all make sense?  Shall I use the built-in test framework?  Are
> there any valued innovations in the last years about software development?
>
> Alan Baljeu
>
>  
>