Hello, itslave, you wrote: I> There is a whole methodology TDD which the unit testing (and as consequence DI) is regarded as of paramount importance, by it popular, fashionable, youth and so on. It perfectly works for an infrastructure, almost for any scale, not bad works for small things and at all does not work even for average projects. That it was clear that such the average project: imagine typical biz-kejz in the form of the 20-page document 12 font, in which 90 % of the text - not water, and logic, and high-level, without to separate instructions. Present code amount for this document and increase this code on 5 - you will receive the minimum for tests. And now control in a head - such cases some tens on each developer. TDD in itself in such conditions does not roll. Therefore only all that is possible in an infrastructure (which just to cover with units-tests), only on all code and only integration tests for business logic (for check of result and to force to work . I> I for example some projects made with universal DI and thousand unit of tests. Not, one thousand units-tests is generally about what. It is typical volume of tests for couple of months for a command from two-three persons. If we is finite about an infrastructural part we speak. I> but here is how to understand, how much it justifies itself - not clearly. So at you the code, turns out, no special value has. In sense, he can be rewritten, not with compatibility. It a little bit depreciates tests, yes. And here when the fallen test shows that we broke behavior and it is caught at the earliest stage, still to the code - here it is pleasant. I> - a DB. It should be, in it the correct data for each test should be prepared. Them it is necessary correctly and to clean. This all time. At steam to one thousand tests runtime can be tightened on half an hour that is very bad. Well so it is mandatory, especially if requests nontrivial, what else variants? The combination the CI-server + SSD + MS SQL Dev edition perfectly works. Minutes, but in any way half an hour. Otherwise already there is an occasion to profile and remove bottlenecks. Well and one thousand integration tests is already much. On a ratio to their simple units-tests it is normally good if 1 to 20. I> Besides frequently it is very easy to arrange race conditions at parallel start of tests - fight because of the data in basis that in turn can force to launch them sequentially that again beats on execution time. Well. It is possible to contrive with a partition on groups, but what alternative? I> - a configuration. If to test the big subsystem for running of the typical scenario it is necessary to execute dance of Nanaian boys of initialization of system. It is frequently sick and heavy. Not, it is heavy only at the beginning, then dares that or otherwise. For the big projects for integration tests an infrastructure generally launch local service not to wait, while it will be got. It certainly even more difficult also demands a separate stage at the assembly to throw there fresh assemblies, but sometimes in another way in any way. However, now in a mode fast development / start, implementers very much ask. Therefore it is on the sly crept from all crutches on standard API but that it did not brake. I> and if variables of type HttpContext are inside used. Current or DateTime. Now evening ceases to be languid - to initialize them correctly painfully, unpleasantly and not always probably. In business logic??? Yes well to shoot for the such. It then if it is required to correct (for example, the user asks printing of forms in advance, for couple of days before actual date) - a heap of the code it is necessary to view and correct.