re: You don't know TDD VIEW POST

FULL DISCUSSION
 

Let's say we are building a simple CRUDL (like 99% of the business project).

  • DAL/DAL/REPO layer mustn't be mocked. Why?. Simply, the objective is to test a function that works with the database. Then, how about to test a function that works with the database, without the database?. It sounds cheating. So, when we test the persistence-layer, we are creating a destructive test, and we should evaluate the result using the database, no less. Example, if we are testing to "insert" we should ensure that the row was inserted. It's not as simple as to test "if it doesn't throw an exception or returned a true" because it is what we are testing (we are testing if the function works).

  • Model class (entity class) is usually logic-less so it can't be tested.

  • Visual layer is, ahem, visual. It is highly hard to test it. In the case of MVC, the visual layer is the template and it's usually logic-less. Even further, the controller layer could be tested but it works in tandem (usually) with the view layer. The controller layer interacts or returns a view layer and it is really hard to test it. It is possible to fill with mocks but, we are saying "we are testing the visual layer without the visual part". It is insane too.

Unit test usually works with the service layer, it's here where Unit test shines but commonly, this layer is thin.

TDD is a step further in unit test but, in my experience, it's hard if not impossible to achieve (without cheating, and most unit-testers are cheaters).

 

DAL/DAL/REPO layer mustn't be mocked. Why?. Simply, the objective is to test a function that works with the database.

But you could just test your DAOs/repositories with, say, in-memory DB instance in isolation. And nothing prevents you from using mocks with other application-level tests.

 

I would still be worried that the in memory database does not behave the same, and this would hide many bugs that would otherwise be caught by using the real database engine.

And usually, it's a common source of bugs.

For example, a classic error is if the regional setting/ collation differs from dev/final server. I regularly prefer to work agnostically (ANSI date for example) but sh*t happens.

Also, what if we are using a persistence library, for example, JPA or Entity Framework, we don't want to test its functionality but the whole experience, i.e. we don't want to test if the "insert function".

code of conduct - report abuse