Activities of "bbakermmc"

Lol, this isnt the use case. It needs to run all the application services and such that are built in to aspnet zero.

<cite>strix20: </cite>

<cite>BBakerMMC: </cite> Strix can you do this for me?

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.

Apparently Its not that simple or I missed something :) Then you can submit it to be included for those of use who want it.

I literally copied and pasted the code from the blog post, and it worked. I don't get what is so hard. The solution has repeatedly been posted.

I just duplicated it on my own. Here is the test class I used in a new project using MSTest, that connects to my local development db. I simply added a reference the the Core.EntityFramework project, and instantiated my db context class.

[TestClass]
   public class DemoTest
   {
       private MyDbContext _db;

       [TestInitialize]
       public void Init()
       {
           var serviceProvider = new ServiceCollection()
               .AddEntityFrameworkSqlServer()
               .BuildServiceProvider();

           var builder = new DbContextOptionsBuilder<MyDbContext>();

           builder.UseSqlServer("Data Source=.\\SQLEXPRESS;Initial Catalog=MyDb;Integrated Security=True;MultipleActiveResultSets=True")
               .UseInternalServiceProvider(serviceProvider);

           _db = new MyDbContext(builder.Options);
       }

       [TestMethod]
       public async Task PassingTest()
       {
           var t = await _db.Addresses.FirstAsync();

           t.ShouldNotBeNull();
       }
}

The test passes, which it could not if it was not connected to my database.

Strix can you do this for me?

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.

Apparently Its not that simple or I missed something :) Then you can submit it to be included for those of use who want it.

I opened an issue about this months ago and put an issue on github, no one has replied with an example yet.

<a class="postlink" href="https://github.com/aspnetzero/aspnet-zero-core/issues/764">https://github.com/aspnetzero/aspnet-ze ... issues/764</a>

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.

Oh look someone else who wants to test with live data because it makes common sense. Just ignore strix and his semantic, most people would want to test against a DB if they are db first to verify that models were generated properly and stored procedures return back proper results... There are NUMEROUS reason to do it be he keeps saying thats not what a unit test is because he doesnt think its best practice.

Not sure why they referenced that previous forum post. This is very easy to do in EF.

<a class="postlink" href="http://www.learnentityframeworkcore.com/configuration/data-annotation-attributes/concurrencycheck-attribute">http://www.learnentityframeworkcore.com ... -attribute</a>

Add the [ConcurrencyCheck] attribute to the fields you want to be auto added to the where clause.

So instead of update x set x.name = Person1 where x.id = 1 it would be update x set x.name = Person1 where where x.id = 1 and x.name = PersonA

Nope, they seem to want to keep it a trade secret for now, even though a bunch of people have asked for it and could better enhance their own products with better templates.

If you want to make life easy and use the pre-built stuff you just need to override the Id column.

This will let you use the IRepo etc which all use Id, but it maps to the column defined in the DB.

public partial class Answer : AuditBase<int>, IEntityDto<int>
    {
        [Column("AnswerId")]
        [Key]
        public override int Id { get; set; }
}

So you would inherit from Entity<type>.

I would assume 5.1 since they just completed most of the mile stones.

Bump. Also added Issue for this.