> On Mon, Aug 16, 2010 at 15:49, Frans Bouma <[email protected]> wrote:
> > 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.
>
>
>
> OK, let me explain what I mean by "the mappings are OK":
> - They are considered valid by NHibernate (this is a single test)
You and I know that that's just not going to be a valid test. You
can have xml mappings which load fine in the factory but barf when you save
an entity, query an entity etc.
> - I can query every mapped entity, verify it loads, and check for ghosts
(I
> automatically generate a test method for each entity)
a single one? So, if you have an entity with 3 relationships, you
generate 1 test to be sure the mappings are OK?
1) it's not enough, you could have missed a directive in the
mappings for the relationships, e.g. it might generate a 1:n query while you
needed a 1:1 query
2) it's doing work that's unnecessary, as you're testing work which
can be done by a machine which doesn't make mistakes.
> How would FNH help me here?
it at least makes sure names etc. match.
> > 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.
>
> I'm sorry to disappoint you :-)
>
>
> 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).
>
>
> ...Except FNH does not have a "validation pipeline". It relies on NH's
XML
> input.
pipeline == code generation engine. So the same input always
generates the same XML. This is a good thing because you then just have to
focus on the input.
> Therefore, by using FNH, I don't gain *anything* on the validation front.
yes you do, the compiler does the name validation part.
> It's just a different syntax and different names for the exact same
concepts
> I map using XML (only it's incomplete).
> For the record, I'm *not* talking about automapping, which DOES add value.
auto-mapping... ah, isn't that the mechanism which is used by people
who are so against db-first, but at the same time are doing just that?
FB
>
> Diego
>
> --
> 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.
--
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.
