Head in the Cloud

Test Driven Development (TDD) is a development/design approach in which we write our tests first, then implement the code to make these tests pass. What TDD is Not These initial tests we write are not unit tests in the traditional sense. I'll repeat that: TDD tests are not unit tests. What are they then? TDD tests are specification tests. They are an example of how to use the thing being built. Sure, we'll use a "unit testing" framework to build, them, but don't get hung up on terminology. The idea is, we're testing, and showing an example of, the API, not testing the logic of an individual piece of the several pieces that make up the implementation of that API.  Let's look at a simple example: Let's take a feature and a scenario: Vendor Lookup Feature: Users can search for Vendors in the system. Scenario: Search by a company name beginning with the search term. Given the following vendors | CompanyName | | Acme Supply | When the company name...

I ran into a scenario where my solution had libraries targeting netStandard2.0 and/or net461. For the libraries targeting just net461, I created a “MSTest Unit Test Project (.Net Framework)” project–the “old” project system. The tests ran fine in Visual Studio, but in my CI build, I wanted to keep it simple and run all the tests with dotnet test. However, this tooling cannot see/run the old test project. So, as an experiment, I tried creating a test project in the new project system, and changing the target moniker from NetCoreApp to net461.  It worked! both dotnet test and Visual Studio can run the tests. It’s worth noting that the library is also the new project system. I haven’t tested if that matters. Test Project XML <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net461</TargetFramework> <IsPackable>false</IsPackable> </PropertyGroup> <ItemGroup> <PackageReference Include="Mic...