https://github.com/dotnet/command-line-api

After a bit of research. It appears that MSTest allows you read the name when you extend test classes, but it does not allow you to modify it. This means i'll probably have to move to NUnit

Figure out how to replicate my unit/integration extension to nUnit with xUnit.

Also, instead (or in addition to?) adding to the test name, I can add traits to organize the test more hierarchically

http://www.brendanconnolly.net/organizing-tests-with-xunit-traits/

Make it easy to test for simple free text vulnerabilities like special characters, sql injections, etc.

Could add a method to the builder that adds the text to every string type.

May want to look at running different theories (parameterized unit tests) for different vulnerabilities

The idea here is to show how easy it should be to swap out data sources.

Could even base the persistence choice on configuration.

A builder could enable complex data creation while keeping each custom dimension more independent (fewer parameter in each signature, mix and match scenarios).

Bogus already works as a builder, but is very generic and requires relatively verbose configuration (*.RuleFor( prop => prop.Rulestuff...))

Key concerns.

• I want to keep my ability to create named scenarios
• keep overall specification short
• Keep ability for instance configuration (like persists to DB or not)
  • no static extentions
• keep my orchestration layer that allows joint configuration and one handle to data preps
  • This means no creating an instance for every case (like with bogus)

Possible solutions

• use a builder behind a normal dataprep (add complexity and extra definition, but fits all requirements)
• Treat my builder like it's immutable or like a c# 8 record (which has the .With() method to create modified instances)
  • This could possibly chew memory

Should be able to create a fixture builder that reflects to fetch attributes on a method. Then, generate a test case (in the fixture builder) for both unit and integration unless an exclusion attribute is present.

https://www.red-gate.com/simple-talk/dotnet/net-tools/testing-times-ahead-extending-nunit/
https://stackoverflow.com/questions/39686622/nunit-get-tests-names-in-a-fixture

Package app core as nuget packages so experimental UIs can be updated and independently from core framework

Enumeration to string mapping would solve issues with enumeration order and make the db more readable

dotnet/efcore#242

http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms-Architecture.html

Create an experimental version of the app with F# to see how the architecture and patterns translate into a functional language.

Functional languages enforce many of the practices I use by convention. It may make sense to just switch.

The idea is that all information needed to run a class is declared via the constructor.

This may seem like excess work and doesn't feel much different than things like Entity framework's configuration defaults.

However, trying to reuse a class outside of the DI setting shows complications. The component cannot be used without configuration that has no explicit ties. Knowledge of the ORM is required to understand why the code doesn't run. Further, configuration via a config file may not always be preferable.

By injecting connection strings, we make this dependency explicit. Within the DI setting, the configuration still happens automagically.

https://adrientorris.github.io/csharp/what-i-get-from-the-preview-of-csharp-8-with-Mads-Torgersen.html#extension_everything
dotnet/csharplang#110

C# will get extensions to instances that can add properties, instance methods, etc.
It may also get Type Classes (like interfaces, but instead of being part of the type definition it is more verified that the class fits the constraint)

What does this mean for my design?

Could I use extension to mimic AOP without dynamic proxies? I.e. extend all types with a log function. These log functions can be maintained separately and different ones can be used based on what log assembly is included? Hmm. This has a hole that I still need funnel info to the logger, which would require to accept the right info to pass on....

Anyway. Questions like that

Write some untested functions and unit tests to indicate they are untested

Must be possible to find because code lens shows test references. It uses roslyn, which we can use too.

What is the right balance of data contract boundaries (DPL currently splits them for the DB, accessor, Managers/Engines, and Clients).

This helps bound changes & makes it easier to expose just the needed data, but results in a lot of data conversions and types. Adding a datatype turns into 5+ new files (migrations, data prep, and call chain types).

How can we reduce the burden of added types?

Before I wrote my own random value generators, so I just referenced them on dataPrep from all places. Now, I use bogus inside of dataprep. However, there are still cases where I want to generate random data outside of dataPrep (like object save_update tests). Do I expose Bogus and require all test assemblies to include Bogus, or do I hide bogus behind a custom class?

• Controller tests
• javascript tests
• What framework/pattern should I use? Primarily Asp.net rendering? Angular?
  • Angular would be easier to test in isolation
  • Non-angular js could be a good example of modular js without a framework
  • writing it as a SPA could be a good chance to show modular interface components

The major question here is how to map back to the primitive with EF.

This would prevent extremely unpleasant refactoring in case of a need for change in id type. It also would enable some flexibility for multiple id types if necessary.

Advice for porting to core
http://www.michael-whelan.net/porting-dotnet-framework-library-to-dotnet-core/

Analysis of this project
https://icanhasdot.net/result?github=farlee2121~2FTestingPatterns

Deep Equal has a PR for core support
jamesfoster/DeepEqual#23

Just mock recently planned core support
https://feedback.telerik.com/Project/105/Feedback/Details/240405-justmock-should-support-net-core

NUnit actually does have support, but it still has some special needs
https://github.com/nunit/docs/wiki/.NET-Core-and-.NET-Standard

TestBase and the TestAccessor are both calling Database.EnsureCreated. Instead call to DataPrep, this way we don't even create a datastore is needed and centralize test storage type in one place.

This could also allow us to remove entityframework as a dependency in the test classes

Are there tools and would it be meaningful to run generated tests against all possible input like in clojure.

The big issue here is understanding what the expected outcome for a set of inputs would be.

Some items to note in readme files

• link to presentation that spurred this project for key testing infrastructure explanations
• IDesign structure. Link to ppt or include a ppt to briefly explain.
• Friend assemblies for hidden internals
• distributed DI configuration for hidden implementations and less repetition in clients
• Reason for DBO models and mapping
• Alternatives and reasoning behind method of integration test reuse
• Reasoning behind result types
• reasoning behind solution structure
• reasoning behind data prep class over direct bogus/autofixture
• reasoning behind datacontracts
  • contrast data contracts with local-use types (DBOs, presentation objects, engine contracts)

Each service layer is responsible for a hiding/isolating a particular type of decision.

Accessors: third parties / stuff out of your control
Engines: calculations
Managers: composition of tasks
clients: program interaction