nhibernate - Dependencies in Acceptance Testing -
me , co-worker having debate. on craptastic legacy project , adding acceptance tests. believes should doing work in gui/watin using low level library query database directly 'end end' test puts it.
we using nhibernate , advocate using gui/watin nhibernate objects assertions in acceptance testing. dislikes dependency of nhibernate in test. assertion have/should have integration tests against nhibernate objects make sure working db way intend @ point there no downside in using them in acceptance test assert proper operation. think low level sql dependence make tests fragile , duplicate business logic in alot of cases.
integration testing in our shop means single component dependency e.g. filerepository/filesystem domain-nhibernateobject/database. acceptance testing means coming in through gui. unit means dependencies have/can mocked/stubbed out , you've got pure test in memory method under test doing real work. let me know if defs off.
anyway articles/docs/parchment opinions on subject can point me @ appreciated.
the reason you'd ever automate tests make things easier change. if weren't changing them, away manual testing. tying tests database make database harder change.
tying them nhibernate objects won't either, i'm afraid!
the users of system won't using database or nhibernate. how benefit (or provide benefit other stakeholders)? how able tell it's working well? if can capture that in acceptance tests, you'll able change underlying code , data while still maintaining value of application. if generates reports data, why not generate same reports , check contents expect? if data read system, can copy of system , see outputs its users?
anyway, that's opinion - keep acceptance tests close business value possible - , here's blog post wrote might help. try behavior driven development group on yahoo, have fair bit of experience amongst them.
oh, , doing integration tests check (n)hibernate bindings excellent idea. saved on couple of projects.
Comments
Post a Comment