.net - TDD: Number of Asserts, and what to actually assert? -

i writing tests using tdd , have come against few queries.

normally when writing unit tests, used use 1 assert per unit tests defined practice , easy see why test failing.

in tdd, practice same, if case design 1 method using tdd going end more 1 unit test - need more 1 assert.

the other concern assert ?

i assert think return object ?

so have create return type (could complex many properties) , ensuring these match on assert, technically 1 assert.

or other way ensure mocks have made along way being called i.e. en moq following

     myservicemock.verify(x => x.itemsreceived(), times.once()); 

so can ensure method called once on mock, classed assert. goes original query, 1 assert per unit test need create additional unit tests ensure other methods on other mocks being called.

what else doing here ?

do assert methods called on mocks or values being returned expect.

really forward input has on this.

i see question has different concerns cover.

first, regarding one-assert-per-test. there different thinking if it's practice or not. fact is, makes things overly complex when followed strictly. tdd should design , clean code, not make rigidly adhere principles. can read topic in robert martin's clean code here.

second, whether want see happens inside object using mocking framework or asserting values depends on kind of test writing.

you can classify tests in either tests verify state or tests verify behavior.

• for state-based tests check values relevant test, e.g. if add function returned right value.
• for behavior-based test use mock objects verify behavior, because outcome isn't trivial verify production code, e.g. think how automatically verify data outputted directly device modem or monitor.

check martin fowler's excellent article mocks aren't stubs topic.

third, honest not sure mean saying:

in tdd, practice same, if case design 1 method using tdd going end more 1 unit test - need more 1 assert.

i assume think have write single test of new method want implement, insane. think implementing divide function. how make sure division works , in case of division 0 error generated? impossible. means need @ least 2 tests method.

fourth, "test" in test-driven development biased term. in general people tend believe in tdd define tests make sure code not broken task testers not developers. however, in tdd should rather consider unit test defining behavior method or class not yet implemented.

the difference seems trivial, powerful statement. moves in position tell program expect before program single line of code. think it, let sink in , try it. makes huge difference. bdd created out of thinking. however, more. can more details bdd it's inventor dan north in this excellent presentation.

all of not view of things, view of great software developers. so, hope gives perspective on tdd , helps proceed on journey,