<cite>BobIngham: </cite> Whose turn is it to get the beers in?
I'll take an IPA!
<cite>BobIngham: </cite> @strix20 Great, just give me the option to test using a database with persisted data! That way @ManojReddy can see the results of the test and create/read/update/delete to his heart's content! Jeepers, you wouldn't honestly expect a test to connect to a production database? I recommend that developers should never even know the meaning of the word production unless the word can be used in same sentence as "whose turn is it to get the beers in"?
Haha.
My point is you can see the exact same effects with a proper integration test that builds a db on test initialize, runs all of your code on an actual database, and then tears it down at the end.
You're also guaranteed to get expected results, which you will never get from a persisted database.
Most of my "argument" comes from the historical context of this discussion, which primarily took place in the github issue, where it was argued that it was necessary and proper to test against persisted data ( an argument in which, every example for, has referenced customer databases, which appear to be production data.)
In any case, the difference between my approach and using a persisted database is literally which database / initial catalog you target in the connection string. In both instances, you're interacting with an actual db context that connects to a real database.
For the record, I am a customer, just like you. I respond to questions on the forums as I have time, to offer guidance and solutions as I can, because this is a community and often times the developers can't get to our questions immediately.
If you create a new test project, make the appropriate EF core DI calls to setup your db context, there is nothing stopping you from hitting live data out of the box. The issue is with test startup and teardown and ensuring that you're not mucking up a good database with your tests.
<cite>BobIngham: </cite> I'm with @BBakerMMC. Everyone seems to be fixated with code-first and the database seems to be downgraded to something which just works. The old adage "rubbish in, rubbish out" should be applied. Testing without a database only tests "rubbish in". Testing against a database allows a DBA to review and change column ordinality (key for user reporting and queries), check column nullability, data- types and then we start to look at replication, database mirroring, recovery procedures etc etc etc. The job doesn't just finish when the input procedures work. For many companies now the key asset is data (include all telecoms companies and ISP's, content providers etc etc). By the time we start to bang badly formatted data into Hadoop and then apply map reduce functionality the consequences of requesting change can be dire. To give a simple example, restricting testing to use in-memory processes such as SQLite means we have to use the dbo schema in SQL Server/Oracle. Most professional DBA's would tear their hair out if they were told that tables have to be created in the dbo schema and prefixed to show that they belong to a particular area of functionality. That restriction alone removes a whole cart load of tools from the DBA's toolbox. I would respectfully suggest an option to use Sqlite or SQL Server/Oracle/MySQL (etc) for testing as a configuration option. Having said that the example unit tests provided by the Zero guys provide an excellent starting point for convention and procedure, well done guys!
What you are describing should absolutely be tested.
By the DBAs who are resposible for the design and integrity of the database. That is why there are unit test frameworks for SQL.
As for using Sql lite vs Sql server, the setup for integration tests using Sql Server isn't any different. I don't think at any point has anyone suggested there's something inherently wrong with writing integration tests against an actual server.
I have, repeatedly, pointed out the reasons why you should not write integration tests against live data.
As I posted in the github issue, this blog is very helpful and informative for how to write integration tests in EF core.
[https://www.davepaquette.com/archive/2016/11/27/integration-testing-with-entity-framework-core-and-sql-server.aspx])
<cite>ManojReddy: </cite> SO again I’ll ask the sameness question.
Test cases which are there in the downloaded project are unit tests or integration tests? And why?
I already answered the question. They are primarily integration tests. This is evidenced by the fact that the use a SqlLite database and there is no mocking framework in place, such as Moq.
I'm not sure how to answer "Why?"
The purpose of Integration Testing is to expose defects in the interfaces and in the interactions between integrated components, in this case the application and domain layers of Asp Zero. It's useful for testing things like ensuring that the UoW is properly used during tenant creation, by ensuring that the process is rolled back during an error. (I'm not describing and actual test, only how integration testing is useful.)
From the tests that I've looked into thus far, I don't really see a compelling reason why they have been written as integration tests, since the bulk of them could easily be satisfied with unit tests. Someone from the Asp Zero team would have to give you guidance as to their reasoning.
<cite>BBakerMMC: </cite> Stix here is a real world example.
We have multiple clients and each database was created at various times. Over the time frame "standard" fields have changed types, clients have come, gone, come back. Because each clients DB can be "custom" but setup with a "standard" we run in to instances where a field in our new app is defined one way because the db documentation says its an 'int' now. Before we launch a client into said new platform we would like to run some standard "unit test" to verify yes if I call XXX end point/proc it will work before said client uses it and the page errors off because the fields new standard is "int" but their DB has it set to a "decimal" the mocking of fake data would say yup pass it works, but for this client it doesnt and they would have errors and it would look bad.
If you only define your DB with EF then sure I guess you can ensure everything is proper but when you dont these types of unit tests are a huge time saver for the QC/Testing team to be able to run a test project and see pretty green check boxes and they can be assured that said client can use said new feature w/out issues.
Unit testing is multi dimensional and live db testing is a valid use case in the REAL WORLD regardless if you think its a best practice or not. When you pay me then I guess I wont care ;) till then I cant rely on not having mock testing, doesnt work and is false security. Or maybe I can give them your number for support 8-) and you can tell them well the unit test was good I dont know why its not working in production now for this client.
What you are describing is easily handled by User Acceptance testing, which can be easily automated with a tool such as Selenium, and can be integrated into your build / test / deployment pipeline just as easily as unit tests and integration tests can. Moreover, UAT is a critical part of QA that should not be neglected, and it's certainly not a good idea to rely on automated tests to ensure your application is production ready.
A Unit test by definition only tests a single layer, and therefore will not interact with a DB (unless it is a unit test written in a SQL framework.)
Most of the tests that come with ASP Zero are integration tests, and they use SQL Lite to set up a mock database. The Asp Zero tests, in particular, seed data during each test. You can see examples of this in the TestDatas folder, as it is used for the OU tests and the payment tests.
It is widely considered unacceptable to write tests against a live database, for two primary reasons: testing against live data can introduce artifacts in your database if the tests crash / fail / are improperly written, and data in a live database is unpredictable, so test assumptions cannot be guaranteed to be true, which defeats the purpose of writing the tests in the first place.
As you can see here: here, this is not supported in EF core, at least not using FromSql.
The feature you are looking for is " Invoking stored procedures in an ad hoc manner to return arbitrary types (covered by #1862)"
It will be included in EF core 2.1.
If you want to map this now, you can use a fake entity as described (not an appropriate approach, in my opinion), or you can use the data reader to handle the mapping yourself as described in the EF repo topic.
I don't think you can do what you're attempting to do.
The only way I know to get results similar to what you want, is to use .FromSql, like the last SO answer suggests.
Can you elaborate a bit more on what you expect the calendar feature to entail? We have a big feature request of our own to build a calendar feature, and I'm interested in how much our requirements will overlap with what you plan to provide?
There is no guide, because every demo will be somewhat different.
But as you can see from the other thread, I've described the process we went through, and the troubles we encountered.
I would add that when I said it took us a week, we only had a single junior developer on the task, so it was not a team effort.
