In this series of posts I'm going to show how to leverage clean code principles when writing functional tests.
The System Under Test
We are going to look at a specific case from the real production system called Easy Freight Booking. I'm allowed to blog about it, because first of all I've got a permission from the owner, to reveal some technical details. In addition to this, the system is exposed as SaaS (Software as a Service) and is publicly available. The purpose of the system is to simplify forwarders booking for end users.
Imagine You own a company which always ships their products. You've got tons of forwarders to work with, where communication with every one of them is different: some of them accepts bookings via email, some provide ftp, where the orders must be placed in a specific format, some of them have their own Web Services, etc. So the system allows to communicate with these forwarders via single user interface, hiding the complexity under the hood.
Posts in this series:
Part 1: The Tradegy
Part 2: Setting Up The Stage
Part 3: High Level of Abstraction
Part 4: A Context for Your Scenario
Part 5: Leverage Fluent Interface