Re: Getting back into C# testing

"Ben Biddington [email protected] [testdrivendevelopment]" <[email protected]> Sat, 6 Sep 2014 09:54:03 +1200
Newsgroups gmane.comp.programming.test-driven-development
Message-ID <CAMkXe7KQhWLafJzcVN3wPwLWe9TE6FVmdPExDA0ikh52oJWeww@mail.gmail.com>
Sort of related - wrt documenting microservices, how do you feel about
having a small number of (likely system) tests like this?:


https://github.com/ben-biddington/richard_iii/blob/master/test/acceptance.tests/an_example.rb
 On 6/09/2014 3:42 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
>
>  
>