Click here to Skip to main content
15,908,675 members
Home / Discussions / Design and Architecture
   

Design and Architecture

 
QuestionRe: Architecture that supports Unit Testing - Is there such a thing as Too Many Interfaces? Pin
Leftyfarrell19-Dec-08 8:08
Leftyfarrell19-Dec-08 8:08 
AnswerRe: Architecture that supports Unit Testing - Is there such a thing as Too Many Interfaces? Pin
Giorgi Dalakishvili19-Dec-08 8:19
mentorGiorgi Dalakishvili19-Dec-08 8:19 
AnswerRe: Architecture that supports Unit Testing - Is there such a thing as Too Many Interfaces? Pin
Mark Churchill22-Dec-08 18:42
Mark Churchill22-Dec-08 18:42 
AnswerRe: Architecture that supports Unit Testing - Is there such a thing as Too Many Interfaces? Pin
CodingYoshi25-Dec-08 21:03
CodingYoshi25-Dec-08 21:03 
AnswerRe: Architecture that supports Unit Testing - Is there such a thing as Too Many Interfaces? [modified] Pin
Jon Rista6-Jan-09 9:01
Jon Rista6-Jan-09 9:01 
GeneralRe: Architecture that supports Unit Testing - Is there such a thing as Too Many Interfaces? Pin
Leftyfarrell6-Jan-09 13:10
Leftyfarrell6-Jan-09 13:10 
GeneralRe: Architecture that supports Unit Testing - Is there such a thing as Too Many Interfaces? Pin
Jon Rista6-Jan-09 13:36
Jon Rista6-Jan-09 13:36 
QuestionRe: Architecture that supports Unit Testing - Is there such a thing as Too Many Interfaces? Pin
Leftyfarrell6-Jan-09 14:13
Leftyfarrell6-Jan-09 14:13 
Yeah, we too were happy to see the EF... haha, and happy again to see it go when we shelved it (for now). We hope to pick it up again and provide a DAL implementation for it when v2 comes out.

You are right about testing the DAL. The Adapter is testable by mocking the DataAction.

The DataAction is testable by providing a connection string to a unit test database. That is where some of the complexity of my original post came from. DataAction method test hits the db, runs a sproc and returns a DataSet or DataTable or DataRow.

The Adapter is like the commander of the DAL, orchestrating the call to DataAction and Mapper.

My original question was hinting at the dependency tree depth. Our current setup has:

Adapter passes DataTable to Mapper and the mapper builds up a User entity and returns it.

Now, some of the hidden complexity within the Mapper is created by the need to support multiple languages (globalization), etc. So internally:

Mapper depends on a static Globalization class, which has a singleton dictionary (collection of supported culture info) that is used in part of the mapping. If the singleton is not populated, then it too needs to call a separate GlobalizationAdapter (to hit the db and get the collection).

It was here that I was wondering about the depth of the unit test. Because the Globalization class is static, I can only mock the GlobalizationAdapter that it uses to go to the db (and avoid a db hit during unit testing).

So when I'm unit testing UserMapping, I'm actually testing:

UserMapping >> Globalization(static) >> MockGlobalizationAdapter

Without mocking the GlobalizationAdapter, the test fails obviously. I guess my question really deals with the best way to handle unit testing classes that depend on static classes or singletons. Or should this dependency chain be re-architected in any way?
AnswerRe: Architecture that supports Unit Testing - Is there such a thing as Too Many Interfaces? Pin
Jon Rista6-Jan-09 17:46
Jon Rista6-Jan-09 17:46 
QuestionDownloading URLs with Python ?? Pin
Fuat Mx13-Dec-08 7:25
Fuat Mx13-Dec-08 7:25 
QuestionTDD, Mocks, and Isolating Legacy Application Components? Pin
Philip Laureano8-Dec-08 21:08
Philip Laureano8-Dec-08 21:08 
AnswerRe: TDD, Mocks, and Isolating Legacy Application Components? Pin
led mike9-Dec-08 4:25
led mike9-Dec-08 4:25 
GeneralRe: TDD, Mocks, and Isolating Legacy Application Components? Pin
Urs Enzler16-Dec-08 8:49
Urs Enzler16-Dec-08 8:49 
AnswerRe: TDD, Mocks, and Isolating Legacy Application Components? Pin
Mark Churchill13-Dec-08 2:35
Mark Churchill13-Dec-08 2:35 
GeneralRe: TDD, Mocks, and Isolating Legacy Application Components? Pin
Philip Laureano13-Dec-08 3:24
Philip Laureano13-Dec-08 3:24 
GeneralRe: TDD, Mocks, and Isolating Legacy Application Components? Pin
Pete O'Hanlon16-Dec-08 10:07
mvePete O'Hanlon16-Dec-08 10:07 
GeneralRe: TDD, Mocks, and Isolating Legacy Application Components? Pin
Philip Laureano16-Dec-08 13:48
Philip Laureano16-Dec-08 13:48 
AnswerRe: TDD, Mocks, and Isolating Legacy Application Components? Pin
Jon Rista6-Jan-09 6:37
Jon Rista6-Jan-09 6:37 
GeneralRe: TDD, Mocks, and Isolating Legacy Application Components? Pin
Pete O'Hanlon6-Jan-09 8:28
mvePete O'Hanlon6-Jan-09 8:28 
GeneralRe: TDD, Mocks, and Isolating Legacy Application Components? Pin
Jon Rista6-Jan-09 9:11
Jon Rista6-Jan-09 9:11 
QuestionHow this can be done in Atomic way? Pin
paresh_joe8-Dec-08 19:27
paresh_joe8-Dec-08 19:27 
GeneralRe: How this can be done in Atomic way? Pin
led mike9-Dec-08 4:30
led mike9-Dec-08 4:30 
AnswerRe: How this can be done in Atomic way? Pin
CodingYoshi10-Dec-08 3:44
CodingYoshi10-Dec-08 3:44 
GeneralRe: How this can be done in Atomic way? Pin
paresh_joe10-Dec-08 23:36
paresh_joe10-Dec-08 23:36 
GeneralRe: How this can be done in Atomic way? Pin
CodingYoshi11-Dec-08 3:34
CodingYoshi11-Dec-08 3:34 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.