To test or not to test ? How much to test ? (Part 2)

In previous article I briefly described problem with balancing between time, budget and writing automated tests. I also wrote what you should do as a minimal set of tests (or ways to avoid writing explicit tests) in order to stay professional but also stay on schedule and budget.

In this article I would like to point out another aspect of writing tests, which is very practical and turns boring and tiresome writing of tests into a very useful tool.

Have you ever seen acceptance tests, tests written by business, people with not that deep understanding of software development ? Such tests may be written as a comment to an agile story or some task in Jira. Let’s see an example. Business product owner wrote a comment, which specifies what steps are to be taken in order to check and accept task/story and say that it is done:

Task: Adding new product

  1. Open application
  2. Click “Products”
  3. Click “New Product”
  4. Enter name, description, category and price
  5. Click “Save”
  6. Application should save this new product and list it in the “Products” screen

OK, so you open IDE, type your code that does what this task is about. meaning you create a screen that has some fields for name, description and price and a dropdown for product category. And a “Save” button that saves data to a storage. Simple. So after some time the screen with the button is created, you open your application, enter some new product data and save it. Done.

Now imagine that this is a little bit more complex form with subforms, and also you are responsible only for one layer and component, be it the “New Product” screen, but saving is done by other component that other team member is responsible for. So you don’t have full control over whole process, and even if you do you shouldn’t trust yourself. After all we are only humans. What if your screen stays untouched but path leading to this screen changes (e.g. Product and New Product buttons are removed) Also this software may change hundreds of times before first release, and between releases. Are you going to check screen manually every time ? Every hundred times ? If you don’t test anything your business partner will open document and perform 6 steps that are there, and will find a bug for you. But it won’t be a nice finding.

So yeah. We need to write some test. But what do we do, we are very limited in time. If you followed my previous article, you should already have validation logic in place, so you don’t have to test millions of variants of user input. But still we need to test this “New Product” screen somehow. Guess how… I’ll tell you how, and this is exactly the minimum business expects that you do (and say “You had one and only one job to do” in case of failure):

  1. Open application
  2. Click “Products”
  3. Click “New Product”
  4. Enter name, description, category and price
  5. Click “Save”
  6. Application should save this new product and list it in the “Products” screen

Yes, I’m repeating myself. You have to perform the very same test that business wrote and described as acceptance test. Yes, really. Your test should do exactly that. Of course you may add some negative path test with data our of range or missing to see how validation mechanism works. If you have time. But you should at least have one test for every acceptance test that is going to be made anyway by business owner. They don’t want to see any problems, they just want to confirm that everything works as they expected. Let’s see how code for test operation could look like (in a form of pseudo-code) :

[TestMethod]
public void Enter_new_product_and_see_if_it_apears_on_list()
{
  var productName="FizzBuzz";
  Button("Products").Click();
  Button("New Product").Click();
  TextBox("ProductName").Enter(productName);
  Button("Save").Click();
  Assert.List("ProductList").ElementExists(productName);
}

Test as a context for code

Look at another very important aspect of this kind of test. This test itself is a description of purpose of your software, a description of process and outcome. So your software code may look clean and self-explanatory but tests give your code additional meaning and context. So use your tests as documentation. Not only documenting expected behavior but also actually doing something – checking your software for this behavior.

That’s it for today !

Dominik Steinhauf

CEO, IT for over 20 years, .Net developer, software architect at Creative Yellow Solutions (formerly Indesys), trainer and software development consultant for banking and energy sectors

If you need help with your software project, or need customized software for your company, contact me at:
dominik.steinhauf ( at) creativeyellow.pl

Leave a Reply

Your email address will not be published. Required fields are marked *