Intro

baangt exists to ease the pain and make the world a better place. Pain in creating test cases, pain in maintenance of test cases and pain caused by rushed high priority fixes for defects in production system. Unnecessary pain for 1000s of people every day. It’s only natural, that we test our test suite using our own functionality. This article shows, how we do it. All examples are taken from the repository https://gogs.earthsquad.global/athos/baangt.

What is baangtDB?

Apart from SimpleFormat and Complex XLSX there’s baangtDB for larger organizations and in cases, where you want to reuse (instead of copy) existing test steps, testStepSequences, testCases or testCaseSequences in more than one testrun. Although it is possible to achive the same with MS Excel it’s definitely more pleasant to work with baangtDB, especially when you have multiple people involved.

In baangtDB we follow the same structure as in Complex XLSX-Format:

  • TestSteps: A single execution step of a larger sequence
  • TestStepSequence: mulitple TestSteps combined into one sequence. TestStepSequences can be subclassed.
  • TestCase: multiple StestStepSequences combined. A TestCaseType is either API or WEB or SAP or any other test method.
  • TestCaseSequence: multiple TestCases in a sequence. All TestCases in this sequence share the same data pool.
  • TestRun: a collection of TestCaseSequences

With baangtDB it’s very simple to reuse common elements in various other structures. For instance if you have a portal login page, you’d definitely use a TestStepSequence with TestSteps for Login-Name, Login-Password, Login-Button to be reused in all your TestCases. If anything ever changes, you’ll have to update only one simple setting and 1000s of test cases will work again.

How do we test baangtDB?

The base is covered by unit tests using pytest. But for functional E2E tests we rely on our own test suite baangt. Here you see a screenshot of the file “BaangtDBFill.xlsx” in the folder “examples”.

Excel file with testrun definition for testing baangtDB

We’ll go step by step through the definition it to see, what it does, but first here’s the data file, which is used for this test:

Screenshot of test data used to test the test suite

  • Line 2: Assuming you have baangtDB running on a local container, this is the URL, that the browser will open
  • Line 3: Little trick to check, if “TestSteps” is visible in the Browser. If not, it means that we’ve to login first, which we do in Lines 4 until 6.
  • Line 8 and 9: We click on TestSteps and on “new Test Step” to create a new TestStep
  • Line 10: We take the value of the column “Name” of the datasheet and write it to the input field “name” of the testStep-Screen in the browser
  • Line 12: We click on the dropdown menu “activity_type” in order to see all available values
  • Line 13: We click on the activity that is specified in data file in column “ActivityType”
  • Line 15: Submit the new TestStep to the database.

After line 15 the app will return to the main screen and we’ll start again with Line 2. This time (from the second run) we’ll not have to login, so we’ll dive right into line 8.

The results

After executing the test run we get a result file showing, how many test cases were executed, how long it took as well as detailed timing information for each testStepSequence

Result of testrun for baangtDB

Summary

It takes maybe 10 minutes to define the testSteps needed for this activity and another 5 minutes to fill in reasonable data to the data file. Once this is done you can run regression whenever there is a commit or whenever you feel like it. Pretty amazing, isn’t it?

All code and example is available for free download and usage: http://gogs.earthsquad.global/baangt