Environment

Our environment had an impact on many of the decisions that were made in our automation project.

• Web Applications with Web Forms and MVC

• Services with WCF and ASMX

• Thin Client with Basic JavaScript

  • We don’t have to worry too much about JS in test. Basically JS provides validation and some minor functionality.

  • Show jQuery code

• C# Thick Codebehinds (sounds nasty and it’s even harder to unit test)

  • Infected with large god methods in codebehind with line number in the hundreds, obvious null ref issues, deeply nested logic, all in on method.

• SOA

  • Large API surface makes it impractical to test every method and permutation of service calls and application state.

  • Service interface with method after method after method

• SQL Server

  • Large amount of logic in stored procedures and functions

  • No real segregation of read and write operations which leads to very little optimization of reads, but also means a lot of complexity going from a relational model to object oriented model. This has an impact on what and how we test.

  • SQL with if statements, case statement, crazy joins and unions, dynamic SQL, loops…

  • Triggers

• Server Environment

  • ASP.Net hosted in IIS

  • Source Control

    • SVN

  • Go Continuous Delivery Server

    • Server and Agent on one server

    • Agent for testing on another server

  • Application Environments

    • 2 Development Environments

    • QA Environment

    • Product Readiness/Staging Environment

    • Client Demo Environment

    • Production

Non-production environments are virtual, but only IT has access to spin up new environments.