entity framework - MVC 5 Unit tests vs integration tests -

i'm working mvc 5 project using entity framework 5 (i may switch 6 soon). use database first , mysql existing database (with 40 tables). project started “proof of concept” , company decided go software i'm developing. struggling testing part.

my first idea use integration tests. way felt can test code , underlying database. created script dumps existing database schema “test database” in mysql. start tests clean database no data , creates/delete bit of data each test. thing takes fair amount of time when run tests (i run tests often).

i thinking of replacing integration tests unit tests in order speed time takes run them. “remove” test database , use mocks instead. have tested few methods , seems works great i'm wondering:

1. do think mocking database can “hide” bugs can occur when code running against real database? note don’t want test entity framework (i'm sure fine people microsoft did great job on that), can code runs against mocks , breaks against mysql ?
2. do think going integration testing unit testing king of “downgrade”?
3. do think dropping integration testing , adopting unit testing speed consideration ok.
4. i'm aware framework exists run tests against in-memory database (i.e. effort framework), don’t see advantages of vs mocking, missing?

i'm aware kind of question prone “it depends of needs” kind of responses i'm sure may have been through , can share knowledge. i'm aware in perfect world both (tests using mocks , using database) don’t have kind of time.

as side question tool recommend mocking. told “moq” framework it’s little bit slow. think?

1. do think mocking database can “hide” bugs can occur when code running against real database? note don’t want test entity framework (i’m sure fine people microsoft did great job on that), can code runs against mocks , breaks against mysql ?

yes, if test code using mocks, it's easy have false confidence in code. when you're mocking database, you're doing saying "i expect these calls take place". if code makes calls, it'll pass test, if they're wrong calls, won't work in production. @ simple level, if add / remove column database database interaction may need change, process of adding/removing column hidden tests until update mocks.

2. do think going integration testing unit testing king of “downgrade”?

it's not downgrade, it's different. unit testing , integration testing have different benefits in cases complement each other.

3. do think dropping integration testing , adopting unit testing speed consideration ok.

ok subjective. i'd no, don't have run all of tests all of time. testing frameworks (if not all) allow categorise tests in way. allows create subsets of tests, example have "databaseintegration" category put of database integration tests in, or "endtoend" full end end tests. preferred approach have separate builds. usual/continuous build run before/after each check-in runs unit tests. gives quick feedback , validation nothing has broken. less common / daily / overnight build, in addition running unit tests, run slower / repeatable integration tests. tend run integration tests areas i've been working on before checking in code if there's possibility of code impacting integration.

4. i’m aware framework exists run tests against in-memory database (i.e. effort framework), don’t see advantages of vs mocking, missing?

i haven't used them, speculation. imagine main benefit rather having simulate database interaction mocks, instead setup database , measure post state. tests become less how did , more what data moved. on face of it, lead less brittle tests, you're writing integration tests against data provider you're not going use in production. if it's right thing again, subjective.

i guess second benefit don't need refactor code in order take advantage of in memory database. if code hasn't been constructed support dependency injection there chance need perform level of refactoring in order support mocking.

i’m aware in perfect world both (tests using mocks , using database) don’t have kind of time.

i don't understand why feel case. you've said have integration tests you're planning on replacing unit tests. unless need major refactoring in order support unit-tests integration tests should still work. don't need many integration tests need unit tests, since unit tests there verify functionality , integration tests there verify integration, overhead of creating them should relatively small. using categorisation determine tests run reduce time impact of running tests.

as side question tool recommend mocking. told “moq” framework it’s little bit slow. think?

i've used quite few different mocking libraries , part, similar. things easier different frameworks, without knowing you're doing it's hard if notice. if haven't built code dependency injection in mind may have find challenging getting mocks need them.

mocking of kind quite fast, you're (unless you're using partial mocks) removing of functionality of class/interface you're mocking it's going perform faster normal code. performance issues i've heard if you're ms fakes/shims, (depending on complexity of assembly being faked) can take while fake assemblies created.

the 2 frameworks i've used bit different ms fakes/shims , typemock. ms version requires level of visual studio, allows generate fake assemblies shims of types of object means don't have pass mocks test through they're used. typemock commercial solution uses profiling api inject code while tests running means can reach parts other mocking frameworks can't. these both particularly useful if you've got codebase hasn't been written unit testing in mind can bridge gap.