ça fait 1 moment que j'avais quitté lemonway, j'ai appris bcp des choses, voici quelque découvert qui peut être useful pour vous mes amis! ## Techno 1) MSSQL Database in a DACPAC file Reference: The .dacpac file is your database's "blueprints." It includes: * Tables and Indexes: Columns, data types, primary/foreign keys. * Programmability: Stored procedures, scalar-valued and table-valued functions. * Views: The logic and definitions of all views. * Constraints: Check constraints, default values. * User-defined types: Custom data types you've created. ### How to create .dacpac file? Create a `.sqlproj` project, put all your `*.sql` inside. Build it `dotnet build` it should generate `.dacpac file` in `bin/debug`. ### How the .dacpac might help 🙏 Lemonway? 1. 🙏 The .dacpac is portable, and can be versioned in git 2. 🙏 Database migration Example: When you want to add a new column to the database * **Today**: You manually write `ALTER Table ADD column...`. You have to combine the `CREATE table` with all the `ALTER table` in order to know what your final table look likes. * **With `.dacpac`**: Just add the new column in the existing `CREATE table` script. The CI/CD is able to compare 2 .dacpac files (v1.dacpac vs v2.dacpac) and generate SQL migration script automatically. It would know that there is a new column in `v2.dacpac`and generate the `ALTER table ADD column..` 3. 🙏 Entity framework scaffolding without SQL Server * **Today:** Amine is developing a new feature which require a new column / table. In order to scaffold the EF DbContext, he will have to "deploy" the new column to a SQL Server (usually a Dev database or his LocalDB). * **With `.dacpac`:** Amine can simply add the column to .sql file, generate the .dacpac and scaffold the EF DBContext from the .dacpac directly: ``` dotnet ef dbcontext scaffold mydatabase.dacpac ErikEJ.EntityFrameworkCore.SqlServer.Dacpac -c MyDbContext ``` Note: I know that you also need some data in the database. A `.dacpac` which contains data is called `.bacpac` (Backup Archive). ## Techno 2) Snapshot testing Reference: **Today**: Look at all the Assert of Gab in your C# tests 🤮 ! * Our test do a lot of Assert - there is so much Assert that we split them into shared functions. These functions reduce the number of repeating Assert codes we have to write, but it also increase the difficulty in maintenance when there are shared Assert codes across tests. * Even though, many meaning-full "Assert" are still missing (until we add them) **With verify**: We can have a lot lot more Assert with barely minimum of codes. Look at [this example:](https://github.com/duongphuhiep/ToolsPack.NetCore/blob/master/tests/ToolsPack.Logging.Tests/CustomSimpleHttpLoggingMiddlewareTests.cs#L59), I wrote one line of code ``` await Verifier.Verify(logsSnapshot, _vsettings); ``` which Assert a [whole big chunk of information](https://github.com/duongphuhiep/ToolsPack.NetCore/blob/master/tests/ToolsPack.Logging.Tests/CustomSimpleHttpLoggingMiddlewareTests.FakeLoggerSnapshotTest.verified.txt) x Complex Objects in depth. This one line of codes should be able to Assert not only the final result but also the intermediary steps.