"We just need the system to do XYZ when the user types "A" into the textbox." We have all been given requirements like these. Tasks like these are commonplace for web development, and with ASP.NET Core MVC, its very simple to pull this off. The steps would look like:

1. Create the frontend razor markup
2. Create/update the view model for the property
3. Drop the code into a class and make the class part of your business rules/services

Testing a scenario like this is easy too, right? Navigate to the site via a browser, type in "A" on the textbox and XYZ should happen. It’s a basic approach to verify something works once (i.e. right now). What happens if you start introducing new rules when the user types "B"? What about rules like typing "B" when another value is already set? Your basic test approach just got more difficult (in many cases it grows exponentially), takes more time to verify, and is subject to a person remembering to test for it.

Usually, on smaller projects, when you have this happen, you code it, test it quickly via the browser and move on. On a recent project, we had a simple area of the code that we did just that. Since our project stakeholders were working closely with us, in an agile team fashion, they saw the screen and started asking questions (mostly amongst themselves) very early on. They asked for changes, introduced new business rules, and turned this code into a very complicated area of logic. It became very apparent that testing via the browser was not going to be enough and would be time intensive. We saw the following issues:

• Testing required intimate knowledge of what the rules were
• Setting up scenarios where the rules would apply
• Remembering to exercise all the rules and taking the time
• Recognizing false positives on screen (which mandates you setup your scenarios perfectly)
• Testing all the rules takes a lot of TIME!

Automated Testing to the Rescue!

Enter unit tests and integration tests. At Omnitech, most of our projects are set up with an automated build and deployment pipeline. Azure DevOps makes this incredibly easy to do and in most cases can be done with 5 - 10 minutes of work. The build pipeline, in particular, has a lot that you can do within it, of interest for this article, is running automated tests. These automated tests can assert that logic is working as intended and can "fail" the build if they do not assert correctly. On our project, we had the build and release pipelines setup, but we had no tests to speak of. We knew that writing the tests, getting the framework setup, scripting scenarios, and mocking objects was going to take a lot of effort and time. After weighing that time against the labor-intensive, repetitive, and error-prone web page testing, we took the gamble that writing automated tests would pay off in the end as the logic continued to evolve.