Skip to content

Consider generating model classes to improve test coverage #12014

Description

@AndriySvyryd

This would allow to reuse the same test code for different permutations of

  • Virtual/non-virtual/Lazy loading/Proxies
  • Auto/backing fields/indexer/no property
  • public/private field/property
  • public setter/private setter/readonly/constructor only
  • Snapshot/Changed/Full notifications
  • new/override/explicit implementation properties
  • nullable/non-nullable properties and navigations
  • CLR default/custom default/calculated property
  • Reference and collection navigations non-initialized/initialized in constructor
  • Navigations to exact type/base/interface
  • Custom Equals/GetHashCode
  • Collection types (IEnumerable/read-only/immutable/etc.)

Activity

  1. added this to the Backlog milestone on May 16, 2018
  2. ajcvickers commented on Jun 5, 2018

    @ajcvickers
    Contributor

    Time-box to 1 week for now, and let's see where we get.

  3. modified the milestones: Backlog, on Jun 5, 2018
  4. modified the milestones: , 3.0.0 on Aug 3, 2018
  5. modified the milestones: 3.0.0, Backlog on Jan 28, 2019
  6. modified the milestones: Backlog, on Sep 4, 2019
  7. AndriySvyryd commented on Sep 5, 2019

    @AndriySvyryd
    MemberAuthor

    Design proposal:

    • Tests are written against interfaces that are implemented implicitly or explicitly by DbContext and model classes
    • The entity class generator takes an IModel created with a sample implementation as an input and outputs the requested DbContext and model classes implementations in .cs files
  8. modified the milestones: , Backlog on Oct 11, 2019
  9. modified the milestones: Backlog, MQ on Sep 11, 2020
  10. added theissue type on Jun 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions