> On Mon, Aug 16, 2010 at 15:23, Vadim Chekan <[email protected]> wrote:
> 
> 
>       On Aug 13, 11:42 am, Diego Mijelshon <[email protected]> wrote:
> > {Unit tests!}
> 
>       Unit test help avoiding *some* bugs and they prove *some*
> correctness.
>       What I'm trying to say is that it is impossible to have full circle
>       unit tests. Even national aerospace laboratories can't achieve it.
>       They allow programmer to not be embarrassed when passing the app to
>       QA, but in no way they are substitution to the QA.
> 
> 
> And when did I say otherwise?
> I never said tests are magic, only that they DO provide a way to catch
bugs,
> because that's what they are for, as opposed to using FNH which, as a
> mapping tool, is no better than XML, and doesn't have catching bugs as a
> target.

        Unit tests test for 'a' situation to be correct, so they prove that
the code works for 'a' situation, namely the situation specified by the
input. You refered to unit tests in the context of xml, as in: 'I can rely
on unit tests to know that the xml mappings are ok'. Unless you write a lot
of tests (read: every possible scenario), it's hard to prove you actually do
cover all bases with your unit tests. I think that's what Vadim tried to
say. 

>       > > > Have you ever used a real refactoring tool (like R#)?
>       >
>       > > I state that xml editing is not easy. And your argument that it
>       > > requires (or is recommended) to use R# just proves my point.
>       >
>       > If you are a professional developer, you'll use the best available
> tools.
>       > Of course you can install the .NET SDK and work in Notepad if you
> want, but
>       > then don't complain about C# editing being hard.
> 
> 
>       Or you use programming techniques that yield reliable code :)
> 
> 
> And what does that have to do with what I wrote?
> Or: how is FNH, *WHICH GENERATES XML INTERNALLY* more reliable than
writing
> that XML myself?
> IMO, hand-written XML *IS* more reliable because it's more documented and
> consistent.

        You really believe that? I truly hope not. 

        Code generation works, if the input is valid and the pipeline is
deterministic. As FNH through its api + compiler proves the input being
valid, the pipeline is deterministic, which means that the output is valid.
I.o.w.: you can't write invalid output with valid input, unless FNH is buggy
(non-deterministic pipeline). 

                FB

-- 
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en.

Reply via email to