TDD and unit testing. Things you may already know.

Let´s make a reminder about TDD (Test Driven Development). The TDD principles tell that you must design based in test, and this means:

  • Make test code first……and the test fails.
  • Make production code, but just the code to pass the unit test.
  • Begin again the cycle with test code first and production code after.

The TDD principles are resumed in acronym F.I.R.S.T.:

  • Fast. Quick execution.
  • Independent and Repeatable: no order or environment dependence.
  • Self-validating. Only return success or error. User not needed to check test results.
  • Timely. Test Code must be made before production code.

Well we are talking too much about TDD in a non TDD post. Please, if you aren´t familiar with TDD, you can follow this user https://dynamicsuser.net/nav/b/vanvugt.

Unit test without TDD is possible, because aren´t the same.

Before explain TDD and unit test, could be good to take a short look at what must do the test code:

  • Arrange. Prepare all previous environment and data for test. This is also known as fixture.
  • Invoke the production code under test.
  • Verify the result is that expected (AKA assert).

And very important, all these steps must be automated, even the assert. So, we can define:

  • Unit test (test code). Code that automate test. Some part of test (arrange, execution or assert) or all of them.
  • TDD, design and program following strictly TDD principles (FIRST).

Why would we want to make test code without TDD?

For the same reason that we make production code: save time. Test code could be a product itself instead of being part of a methodology.

TDD is the better way to do quality software. But not all the people use TDD. And not all the software we do is quality software. But even if you don´t do TDD you could propose use test code.

Let´s see tree real cases using unit test without TDD.

Case 1: Third party software. Learning test.

Scenario.

We bought a specific Navision software from other vendor.

This module is a legal modification that gets sales invoice headers, and create an XML file for a tax office declaration.

Test responsibility.

Test other vendor isn´t our responsibility. But we did a very simple test code to do:

  • Get the last sales invoice.
  • Call the production code creating tax XML file.
  • Check that the amount and VAT registration number is the same in XML file and NAV Sales invoice.

Code:

[Test] VATNumberAndAmountsInXMLSameThanInvoice()

GetLastSalesInvoiceHeader(SalesInvoiceHeader);

OtherVendorModule.CreateXMLFile(SalesInvoiceHeader,FileName);

 LibraryXMLRead.Initialize(FileName);

Assert.AreEqual(SalesInvoiceHeader."VAT Registration No.",LibraryXMLRead.GetNodeValueInSubtree('VatRegNode','VatRegNo'),ErrFieldXML);

 EVALUATE(AmountInFile,LibraryXMLRead.GetNodeValueInSubtree('sii:VatDetail','VATBase'));

Assert.AreEqual(SalesInvoiceHeader.Amount, AmountInFile, ErrFieldXML);

 

We used two existing test Codeunits in NAV test toolkit:

LibraryXMLRead               Codeunit             Library - XML Read         

Assert                                   Codeunit             Assert  

Why?

We said test other vendor code not our responsibility, but we did a little test. Why? Two good reasons:

  • Learning tests. This means make tests to learn how other people software work, and very important, how to execute it from code. This is useful, you must know how the code you sell is doing. Robert Martin talk about this kind of tests in his famous book Clean code.
  • Test new releases. When we receive a new release (in this case very often), we execute this test code to ensure basic features still work and work as we know.