Architecture Evaluation Methods

There indeed are industry standard methods such as

1. Software Architecture Analysis Method (SAAM),
2. Architecture Trade-Off Analysis Method (ATAM),
3. Architecture Reviews for Intermediate Designs (ARID).

The Carnegie Mellon Institute (SEI) created a scenario-based software-architecture evaluation method that is known as the Software Architecture Analysis
Method (SAAM). This method was later modified to address the evaluation of risks, trade-offs, and opportunities among different qualities. The modified method is known as the Architecture Trade-Off Analysis Method (ATAM). This method
has been further extended for analyzing cost-benefit and schedule implications. The extended method is known as the Cost Benefit Analysis Method (CBAM).

Mock Testing

Mock objects are special objects that mimic real objects for testing.

Mocks typically follow a four step sequence : setup (data and expectations), exercise, verify, teardown



1. Understanding One : Mocks are dynamic stubs ?

MSDN Article




2. Understanding Two : Mocks are not stubs

Martin Fowler's Article

There are two differences

a. How test results are verified : Stubs do state verification, Mocks do behavior verification.

Mocks use behavior verification, where we instead check to see if the SUT (System Under Test) made the correct calls on the mock object. We do this check by telling the mock what to expect during setup and asking the mock to verify itself during verification.

b. The way testing and design play together : Classic vs Mockist

The classical TDD style is to use real objects if possible and a double if it's awkward to use the real thing. So a classical TDDer would use a real "collaborator or secondary object" and a double for the a service. The kind of double doesn't really matter that much.

A mockist TDD practitioner, however, will always use a mock for any object with interesting behavior.

An important offshoot of the mockist style is that of Behavior Driven Development (BDD).