176

Re: About confusion with repositories and DAO

Hello, Gattaka, you wrote: G> Hello, gandjustas, you wrote: G>> Hm... And you wrote such tests? In tests of 80 % of operation - preparation, 10 % execution and 10 % check. When you drive tests for real basis there is one small problem - the basis stores a state. And for different tests the different data is necessary. To write down the reference data each time - the code of tests swells in times, not to write down - tests start to depend on the start order. G> before start of the test the basis is cleaned. There is all anew, the case is launched. The code of tests swells in times. Because to make normal checks on the same reference data it is impossible. You at least should check three cases - "0,1, n". Well or simply to reconcile that the covering tests will be at most 20 %. G> For basis creation there is something like masters of creation, the code of creation of basis at the majority of tests identical, differs slightly. Or more radical decision, you for the test store  bases. It if at you migration of versions is adjusted...

177

Re: About confusion with repositories and DAO

Hello, IT, you wrote: IT> It at whom as well as looking that we understand as it. IT> is not present. Insulation function moved in LINQ. And itself DAL more  it is not necessary. The big uncles live in peace the determinations invented by them? MSDN: LINQ is a set of features that extends powerful query capabilities to the language syntax of C#. LINQ introduces standard, easily-learned patterns for querying and updating data, and the technology can be extended to support potentially any kind of data store. The a. net Framework includes LINQ provider assemblies that enable the use of LINQ with a. net Framework collections, a SQL Server databases, ADO.NET Datasets, and XML documents.

178

Re: About confusion with repositories and DAO

Hello, gandjustas. I want to make a reservation here that about what I tell all I do not consider true in ultimate authority. Nevertheless, at me was pieces three big projects with integration and units-tests in which I personally saw all described problems and itself was engaged in their elimination. You wrote: G> You substitute concepts. If it is possible to write a unit the test, it at all does not mean that they can check up something. I some times saw programs with a test coverage close to 100 %, it is natural units-tests. In them there were bugs in a large quantity. G> if at the grandmother something was, it would be not absolutely the grandmother. Did not do integration tests for the reason described by you above. To cover with integration tests a significant part of the program with reasonable expenses it is impossible. And a unit tests it is possible. Here only units-tests do not check. I do not substitute concept. If to pursue only for a covering of the code tests it is clear why units-tests check nothing. UT it should be easy to throw out, rewrite, write from zero and to launch. The covering is very indirect index. Tests it is necessary to check a unit the same as also the remaining code that there was no writing of tests for the sake of tests. As a matter of fact, it is saving anchors of the rock-climber (the developer) if it is figurative. Them can be not much, but there where it is necessary. G>>> Here you have a method - does sampling, processes, saves. It is your scenario. G>>> for the test you substitute a repository for banal implementation on list <t> when the method simply gives the list. Also you check that the data in the list exchanged. G>>> you wrote the code which does handling, and SaveChangesAsync forgot. The test transits. At start does not work, stupidly happens nothing. _>> I would saw on some methods which on-separateness can be tested. I.e. sampling would be checked by integration test, handling - a unit the test, saving - integration. Thus in a unit the test sampling and saving I . G> In my opinion anything would not change. G> the code was about such: G> G> void F (Repo repo) G> {G> var xs = repo. GetXsByXXX (); G> foreach (var x in xs) G> {G> x.y + = 1; G>} G>//repo. SaveChanges ();//this line lost at refactoring G>} G> [Test] G> void Test () G> {G> var mock = new Mock (); G> var xs = new [] {...}; G> mock. Xs = xs; G> F (mock); G> Assert. IsTrue (xs. All (...) ); G>} G> G> the Test green, the code does not work. G> you suggest to cover GetXsByXXX with integration test that is not meaningful, there primitive request. To cover SaveChanges with integration test that too has no  and to write a unit-test for F that does not give actually check. Here it is necessary correctly to answer still questions . If it is interesting, tell, in what an overall objective of this method F (on it depends as it should be written and what tests for it to write)? And as it is interesting, you of turnips should store a state and  the data, or is simple  an interlayer between ORM (EF, for example) and BO? G> At me the scenario is even more interesting is: G> In application a calendar. At creation of new event it is necessary to check up that event is not intersected with the existing. It is a lot of events, to pull all in storage it is impossible, it is necessary to check request to basis. And the important condition - you carried, you cannot use Linq, is mandatory text requests. G> Write a unit-test for check. For check of that? , dynamic , check conditions? The description is not enough normally to answer a question. G> I this task to the troll of apologists of units-tests. We can try on to understand. To Someone precisely in + totals will. If without attempts to convince and impose the judgement

179

Re: About confusion with repositories and DAO

Hello, gandjustas, you wrote: G> Hello, another_coder, you wrote: _>> Though and in the theory but if all is written normally... At green units-tests, but red integration, on 100 % it should be clear where and that fell. G> and what for then units-tests if in a reality check becomes only the integration are necessary? Not only, and set. I.e. for example, you know that method Save at you is not covered tests. The case when all units green, but integration are not present says, generally, that the logic is correct, and here the moment with record does not work. And after all can be so that integration green, and 5 of 20 unit of tests red (even 1). If you consider that the integration should be red always, when at least one unit the test red you are mistaken. The sheaf of two systems can work for you normally.

180

Re: About confusion with repositories and DAO

Hello, gandjustas, you wrote: G> Hello, Gattaka, you wrote: G>> Hello, gandjustas, you wrote: G>>> Hm... And you wrote such tests? In tests of 80 % of operation - preparation, 10 % execution and 10 % check. When you drive tests for real basis there is one small problem - the basis stores a state. And for different tests the different data is necessary. To write down the reference data each time - the code of tests swells in times, not to write down - tests start to depend on the start order. G>> before start of the test the basis is cleaned. There is all anew, the case is launched. G> the code of tests swells in times. Because to make normal checks on the same reference data it is impossible. You at least should check three cases - "0,1, n". G> Well or simply to reconcile that the covering tests will be at most 20 %. G>> For basis creation there is something like masters of creation, the code of creation of basis at the majority of tests identical, differs slightly. Or more radical decision, you for the test store  bases. It if at you migration of versions is adjusted... G>  In tests it is possible to use TransactionScope with minimum insulation. Certainly, it does not cancel attention to that there were no dependences between tests, but strongly facilitates creation of the necessary data.

181

Re: About confusion with repositories and DAO

Hello, gandjustas, you wrote: G> Hello, Gattaka, you wrote: G>> Hello, gandjustas, you wrote: G>>> Hm... And you wrote such tests? In tests of 80 % of operation - preparation, 10 % execution and 10 % check. When you drive tests for real basis there is one small problem - the basis stores a state. And for different tests the different data is necessary. To write down the reference data each time - the code of tests swells in times, not to write down - tests start to depend on the start order. G>> before start of the test the basis is cleaned. There is all anew, the case is launched. G> the code of tests swells in times. Because to make normal checks on the same reference data it is impossible. You at least should check three cases - "0,1, n". G> Well or simply to reconcile that the covering tests will be at most 20 %. There is still an approach where "move" the data. We suppose at you system where in your subject the area is some license, allowing to create objects. And so you load the license, then create the first object on which check the test. Then without loading the license and without deleting the first object create the second object and on it check the second test. But personally I did not practise such approach. G>> for basis creation there is something like masters of creation, the code of creation of basis at the majority of tests identical, differs slightly. Or more radical decision, you for the test store  bases. It if at you migration of versions is adjusted... G>  And what the such? Tests it is the same code, and the same rules there work as by software development...

182

Re: About confusion with repositories and DAO

Hello, Baudolino, you wrote: IT>> Is not present. Insulation function moved in LINQ. And itself DAL more  it is not necessary. B> the big uncles live in peace the determinations invented by them? The big uncles live first of all in the common sense world. And small uncles (or the big children?) do not distinguish in a kitchen garden an elder, and in Kiev the uncle. B> MSDN: B> B> LINQ is a set of features that extends powerful query capabilities to the language syntax of C#. LINQ introduces standard, easily-learned patterns for querying and updating data, and the technology can be extended to support potentially any kind of data store. The a. net Framework includes LINQ provider assemblies that enable the use of LINQ with a. net Framework collections, a SQL Server databases, ADO.NET Datasets, and XML documents. Also what? With what you here do not agree and how it contradicts my "invented" determinations?

183

Re: About confusion with repositories and DAO

Hello, another_coder, you wrote: _> I do not substitute concept. If to pursue only for a covering of the code tests it is clear why units-tests check nothing. UT it should be easy to throw out, rewrite, write from zero and to launch. The covering is very indirect index. Tests it is necessary to check a unit the same as also the remaining code that there was no writing of tests for the sake of tests. As a matter of fact, it is saving anchors of the rock-climber (the developer) if it is figurative. Them can be not much, but there where it is necessary. Then there is a reasonable question - whether there are units-tests of efforts expended on them? And after the second a question - it is necessary  to cover is mandatory the program abstractions for UT if expenses on UT exceed favor? G>> you suggest to cover GetXsByXXX with integration test that is not meaningful, there primitive request. To cover SaveChanges with integration test that too has no  and to write a unit-test for F that does not give actually check. _> Here it is necessary correctly to answer still questions . If it is interesting, tell, in what an overall objective of this method F (on it depends as it should be written and what tests for it to write)? And as it is interesting, you of turnips should store a state and  the data, or is simple  an interlayer between ORM (EF, for example) and BO? Very interesting question, considering that talk began that the repository forms for insulation of the program from "details" of operation with storage. And here it turns out that these "details" come out on top. Let is an interlayer to EF. _> For check of that? , dynamic , check conditions? The description is not enough normally to answer a question. For method check. The pseudocode such: bool F (Event evt) {string query = buildQuery (evt); ResultSet rs = db.query (query); if (rs. Count> 0) {return false;} else {db.addEvent (evt); return true;} } The main logic is concentrated in creation of text request, but  so difficult that fine details in request and in the data can lead to strongly different results. That is simply to check a line on correspondence "reference" it is impossible, for a warranty of a correctness it is necessary to send request in storage. Any method it is possible , but to repeat behavior of storage - expenditures of labor in hundreds times exceeding application. Green UT should show that the code fulfills correctly in  if the basis is accessible. G>> I this task to the troll of apologists of units-tests. _> we can try on to understand. To Someone precisely in + totals will. If without attempts to convince and impose the judgement

184

Re: About confusion with repositories and DAO

Hello, another_coder, you wrote: _> Hello, gandjustas, you wrote: G>> Hello, another_coder, you wrote: _>>> Though and in the theory but if all is written normally... At green units-tests, but red integration, on 100 % it should be clear where and that fell. G>> and what for then units-tests if in a reality check becomes only the integration are necessary? _> not only, and set. I.e. for example, you know that method Save at you is not covered tests. The case when all units green, but integration are not present says, generally, that the logic is correct, and here the moment with record does not work. And after all can be so that integration green, and 5 of 20 unit of tests red (even 1). _> If you consider that the integration should be red always, when at least one unit the test red you are mistaken. The sheaf of two systems can work for you normally. You left from the answer to a question. What for generally units-tests, what their value if UT can be green, and integration - red are necessary. Other question depends on the answer to this question also - whether it is necessary to isolate generally the application code from details of operation with storage? After all we perfectly understands that in a reality the application working with basis, does not start to work with a web service after simple changeover of a repository. Therefore we can try to find other reason of appearance of such abstraction.

185

Re: About confusion with repositories and DAO

Hello, another_coder, you wrote: _> In tests it is possible to use TransactionScope with minimum insulation. Certainly, it does not cancel attention to that there were no dependences between tests, but strongly facilitates creation of the necessary data. It after some persons stated, what the repository forms to isolate application from data access "details"? Suddenly at us "on other" the end generally we cannot supervise a web service, which state directly?

186

Re: About confusion with repositories and DAO

Hello, gandjustas, you wrote: G> Hello, another_coder, you wrote: _>> Hello, gandjustas, you wrote: G>>> Hello, another_coder, you wrote: _>>>> Though and in the theory but if all is written normally... At green units-tests, but red integration, on 100 % it should be clear where and that fell. G>>> and what for then units-tests if in a reality check becomes only the integration are necessary? _>> not only, and set. I.e. for example, you know that method Save at you is not covered tests. The case when all units green, but integration are not present says, generally, that the logic is correct, and here the moment with record does not work. And after all can be so that integration green, and 5 of 20 unit of tests red (even 1). _>> If you consider that the integration should be red always, when at least one unit the test red you are mistaken. The sheaf of two systems can work for you normally. G> You left from the answer to a question. What for generally units-tests, what their value if UT can be green, and integration - red are necessary. G> other question depends on the answer to this question also - whether it is necessary to isolate generally the application code from details of operation with storage? After all we perfectly understands that in a reality the application working with basis, does not start to work with a web service after simple changeover of a repository. Therefore we can try to find other reason of appearance of such abstraction. I answered it. Sense that units-tests show correctness of the used algorithms. If they  also are correctly written, you can be assured that in known scenarios at you all is normal. But always there is a share of the unknown person and here there's nothing to be done. Integration tests check not algorithms, and a sheaf between systems. I.e. It is possible not to be engaged in start preparation of everything, and, for example, to initialize the data before saving and to check up that it fulfilled. These are two types of tests not dependent from each other and showing an overall picture in aggregate. Tests end-to-end, which confuse many with integration, are necessary in very restricted kol-ve, sufficient for system sanity check as a whole.

187

Re: About confusion with repositories and DAO

Hello, gandjustas, you wrote: G> Hello, another_coder, you wrote: _>> In tests it is possible to use TransactionScope with minimum insulation. Certainly, it does not cancel attention to that there were no dependences between tests, but strongly facilitates creation of the necessary data. G> it after some persons stated, what the repository forms to isolate application from data access "details"? Suddenly at us "on other" the end generally we cannot supervise a web service, which state directly? As I understood, here it was a question of integration tests. In them not to be isolated.

188

Re: About confusion with repositories and DAO

Hello, gandjustas. And so, I add: 1) a repository simply interlayer (facade) to EF. 2) it is necessary to check up generation of requests () the Original pseudocode: bool F (Event evt) {string query = buildQuery (evt); ResultSet rs = db.query (query); if (rs. Count> 0) {return false;} else {db.addEvent (evt); return true;} } G> Green UT should show that the code fulfills correctly in  if the basis is accessible. Here I will correct: UT shows that the algorithm of generation of requests works how the developer assumes it should, and it shows integration test as then works on __ a surrounding. It is not necessary to suppose that tests it is stopped up all possible holes which even yet have been not met. That I would make... 1) it is necessary to have possibility : db.query (query) db.addEvent (evt) I do not know that from myself represents db. It is the interface? How sozdaetsja/inzhektitsja? 2) buildQuery (evt) it is necessary to transfer to other essence which is engaged in its creation. Then: - it will be possible to test separately - as consequence, it will be possible  in tests For example, we carry out in another class QueryBuilder: IQueryBuilder {} At this stage the code can to look, presumably, so, after changes: bool F (IDb db, IQueryBuilder qBuilder, Event evt) {string query = qBuilder.buildQuery (evt); ResultSet rs = db.query (query); if (rs. Count> 0) {return false;} else {db.addEvent (evt); return true;} } 3) In this case on method F it is possible to write such a unit tests (we check algorithm branches): - should return false, if rs. Count> 0 - should return true, if rs. Count <=0 - should cause addEvent with transferred evt, if rs. Count <=0 4) Separately it is possible to test generation of requests in a method buildQuery class QueryBuilder. I do not know details, but the developer wrote algorithm of generation, means can, submitting on an input different evt, to check up creation of lines corresponding for them. Some unit of tests turns out. 5) I suppose that in db.query only the mechanism of a call of a DB. Therefore, in integration test we check that the transferred request in db.query returned that was required by request. This test shows that this method obtains the data from basis and adequately fulfills requests, as it is required. As a result it turned out UT 3 + and IT 1 = 4 or more tests. Now we present that made any changes. It can appear so that all , but for some reason does not work on . It is a problem not tests, and a test surrounding. We assume, there  the table, a method query falls. Here it is clear what to do. At you all is checked, except this moment. Means, special integration test it is necessary to check up this moment, and a method buildQuery  so that, for example, it put (nolock). The thought is clear? What questions, variances?

189

Re: About confusion with repositories and DAO

Hello, another_coder, you wrote: _> I answered it. Sense that units-tests show correctness of the used algorithms. If they  also are correctly written, you can be assured that in known scenarios at you all is normal. But always there is a share of the unknown person and here there's nothing to be done. Integration tests check not algorithms, and a sheaf between systems. I.e. it is possible not to be engaged in start preparation of everything, and, for example, to initialize the data before saving and to check up that it fulfilled. These are two types of tests not dependent from each other and showing an overall picture in aggregate. _> tests end-to-end, which many confuse with integration, are necessary in very restricted kol-ve, sufficient for system sanity check as a whole. If you not in course the system as a whole is and are system. Esteem at least the theory of systems. Separate parts of system do not define its complexity, and only designate it. System complexity is defined by communications between its components. Integration tests just test  system components, as though you them did not name.

190

Re: About confusion with repositories and DAO

Hello, IT. IT> Integration tests are tested just  components of system by you are right.