eShopOnWeb Architecture (14/16) – uses parameterized tests
I love parameterized tests.
Instead of adding many different test methods with different inputs set in the method body?we have one method and pass in the inputs and expected output(s)?for each test we want to run as params to the method (one per line). This means less test methods (so test logic easier to change) and that we can quickly see all inputs and expected outputs for a particular method together. In addition to this our results from each row of params will be grouped together.
Below is one example from eShopOnWeb which uses xUnit, but most test frameworks will support the concept.
In this particular test the query inside the specification is being tested.. for me this is a?little bit too low level of a test. There’s very little I can refactor in the specification without changing its signature and thus?requiring a change to the test?so personally I would indeed test this stuff but would do it through the context of its parent API or use case which appears to be…
CatalogViewModelService.cs -> GetCatalogItems
and
CachedCatalogViewModelService.cs -> GetCatalogItems
Follow for daily .NET posts | Microsoft MVP | Senior Software Engineer
3 年Part 1 - uses marker interfaces to communicate intent and enforce design constraints https://lnkd.in/d-PWGS3J Part 2 - uses Value Objects to model domain concepts without identity https://lnkd.in/dX_eFuti Part 3 - uses custom exceptions to more explicitly express what has gone wrong https://lnkd.in/dHpp2-E3 Part 4 - uses the MediatR library to keep controllers thin https://lnkd.in/dX7VfD6i Part 5 - makes regular use of Guard Clauses https://lnkd.in/d--hmXz5 Part 6 - uses private setters and non default constructors to support encapsulation which helps keep the model valid https://lnkd.in/dEwY_iep Part 7 - encapsulates navigation collections so consumers can’t edit them directly https://lnkd.in/dk5DXRKh Part 8 - uses in memory caching to avoid sending unnecessary queries to the DB https://lnkd.in/dg_Y5qUx Part 9 - uses the Aggregate root pattern to ensure child objects are not manipulated out of context https://lnkd.in/d46XBjeC Part 10 - has unit tests which test very low level implementation details https://lnkd.in/dd69BEpU Part 11 - uses AutoMapper https://lnkd.in/deeCwcBa Part 12 - uses the repository and specification pattern https://lnkd.in/dd6RiDUy Part 13 - has some single implementation interfaces https://lnkd.in/drkhgk8T Part 14 - uses parameterized tests https://lnkd.in/dgqTTP4F Part 15 - has a really nice example of the Interface Segregation Principle https://lnkd.in/dgkn5fqx Part 16 - uses clean architecture https://lnkd.in/d-bS24cY
Practical .NET and Software Architecture Tips | Microsoft MVP
3 年This is a very good way to write your test in my opinion. Another amazing feature of xUnit worth mentioning is using TheoryData to write strongly typed tests. Here's an article explaining the concept: https://andrewlock.net/creating-strongly-typed-xunit-theory-test-data-with-theorydata/