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 > > >