search

sjh37 / EntityFramework-Reverse-POCO-Code-First-Generator

EntityFramework Reverse POCO Code First Generator - Beautifully generated code that is fully customisable. This generator creates code as if you reverse engineered a database and lovingly created the code by hand. It is free to academics (you need a .edu or a .ac email address), not free for commercial use. Obtain your licence from
https://www.reversepoco.co.uk/
Other
710 stars 227 forks source link

Reviewed tests #727

Closed bobbyangers closed 3 years ago

bobbyangers commented 3 years ago

Although many files have changed (only in the test projects); some where very minor and should be really quick to review.

  1. Categorized tests per Db Type, CI don't require a database.
  2. Added a few utility classes to centralize the generation of DBContext and connection string
  3. added the scripts to generate the postgre Northwind.
  4. added missing "TestComparison" (need review/approval)
  5. added support for UserSecrets to allow local values for config without affecting the project a. moved "hard-coded" connection string to config file
  6. Separated SingleDatabaseReverseEngineerTests per Db technology (want to add SQLite)
  7. Changed dependency to UserProfile path in favor of %TEMP% (we could also use the bin\generated folder
  8. Replace "C:/S/Source" to current "AppDomain.CurrentDomain.BaseDirectory" before comparing string (for SQLCe)

    this is done dynamically and does not change the SCC file

To be done: Readme.md to generate/create postgre Add support for SQLlite (different issue/PR)

It goes without saying that I can modify/change anything you prefer .

bobbyangers commented 3 years ago

I have submitted a bug to EFCore,

incorrectly generate CREATE SEQUENCE when using decimal

regarding the generation for decimal. It's currently under review.

sjh37 commented 3 years ago

It broke a few things. I have to revert it for now, and bring in the changes manually bit by bit. This was probably too large a change in a single PR.

bobbyangers commented 3 years ago

Hi @sjh37.

I am reLly sorry to hear that. Maybe I can help?

The tests are all runnings... did not change any code from your generator.

My guess is that the db version you are running match/don't matche the scripts.

I think if we just put a samll effort to identify, it'll put thinks back on track.

Started the work for sqllite. if you revert... then i'll have to abandon that.

That is why, tests should not rely on local paths, and also, not rely on snowflake copies of local bd. the db scripts need to be kept current in the scc and be able to drop and recreate the db any time needed.

Let me know.

sjh37 commented 3 years ago

I want to get a release out for VS2022 first, then I'll start to pull in your changes bit by bit. I have to be careful with the C# version, and what I can use in the T4 template because some users still use VS2015 etc and don't have the latest language feature. Same for .Nuget packages. For .NetCore3 libraries I stick with v3. of the nuget packages, same for .NetCore 2, v2. for EF, .Net5 obviously can use the latest nuget versions.

bobbyangers commented 3 years ago

I understand, thank you for the explanation.

I understand for the generator, but for the tests, it should not matter at all.

When you have more time to make the tests less "snowflake" (ie only work on your machine), let me know, we try again.

bobbyangers commented 3 years ago

Maybe once you release, we can review my orginal PR and break it down in a few steps, per test project, and as a first step, not migrate the nuget packages. Although I still thing that test projects are independent of the Generator project/your final product. At least we should make it so.

sjh37 commented 2 years ago

Released v3.6.0 - This should improve testing. Still making testing better and less of a snowflake.