baangt/docs/_build/html/_sources/OverviewUsage.rst.txt

============================
What is ``baangt``
============================

Testing software has always been a challenging field, and it's not getting easier or simpler, as overall complexity in corporate
and other applications skyrockets. Release cycles in larger corporations are often long because of inefficient regression
tests. Also costs of software updates, upgrades and forward development are heavily impacted by too little test coverage.

**To stop praying when you release to production, you need to start serious testing!**

With ``baangt`` you have one *open source* solution for all your test stages and needs. Be it Frontend with Webbrowser, API,
graphQL, SOAP, oData or chromium related App-Tests. You'll use one toolset, one database per stage and one reporting to
see at any given moment, how your stages and applications are doing and if it's safe to release the current state of one
stage to the next.

    ``baangt`` is optimized to be super easy to start, and flexible when your demand grows.

The fastest, simplest way to record test cases
----------------------------------------------

If your requirements are pretty basic, you'd start using ``baangt`` with a simple Excel-Sheet as source of Testcase definition and
Testdata definition. This is super fast, very easy even for end-users but has limited flexibility, even though it comes packed
with all features of the higher end solutions like reporting, fault tolerance, screenshots in case of errors and much more.


More powerful and still simple ways:
------------------------------------

As your requirements grow you want to have Testcase and testrun definition separately (e.g. you want to execute the same
test cases on different stages of your system landscape (Pre-Quality, Final-Quality, Dev) and not for every heartbeat test
you would want to run through your 1000s of records of test data. Maybe you will have a SQL-Query in your Excel based data, which changes
data records dynamically or per stage or per version, that you want to test for.

Things are not so simple in this stage, but still simple enough for technically versed business department to run high
quality tests on all stages by themselves.

Even after the point, where you need technicians to integrate baangt with your CD/CI-Pipeline`s build-management tools,
the maintenance of data and test sequence can be done without ANY other tools (except Excel or OpenOffice) easily by the
people who know best what to test: Your business department.

Hey, why not do everything in Excel?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

There is one serious drawback from this flexibility: it's **change**. Of course you started with 1 sheet, but later had some additional
requirements and simply added a second sheet to cover those without changing the definitions of the first excel sheet.
You're still happy as you need both behaviours tested (imagine one test set for regional customers and another test set
for customers from other countries). Great. Everything works.

After having some serious problems in production and fixing
those defects, you decide to write a testcase to mimic a certain user behavior (e.g. navigating back and forth multiple
times, deleting and re-adding objects from a shopping cart, etc.). The basic test sequence would still be the same as in
the other two cases, but for a specific card you'll need changes. Simple. You copy one of the original sheets and adjust
accordingly. You immediately sleep better because now also those cases are part of your growing regression test set. Wonderful.
You continue like this for 2 months, end up with 2 or 3 datafiles and 20 test case definitions. That's not uncommon. What is also
not uncommon is "**Change**". For more direct communication with the endusers the AUT (Application under test) get's enriched
with a Sentry-Popup. Wonderful idea. But wait... It's not so great after all, because now you have to update 20 test case
definitions with a way to deal with the new popup. Imagine corporate environments where we have many thousands or many tens of
thousands tests.

Subclassing for multiply used functionality
-------------------------------------------

The existing classes ``baangt.TestCase.TestCaseMaster`` and ``baangt.TestStep.TestStepMaster`` can easily be subclassed
and enriched with static functionality - even when you use the Excel version of ``baangt.py``. Yes, you'll need to know
some basics of powerful Python Language and most probably an IDE.

An example could look as simple like this:

::

    from baangt.TestStep import TestStepMaster

    class myTestStep(TestStepMaster):
        def execute():
            self.driver.goToURL("http://www.google.com")
            self.driver.findByAndSetText(xpath='//input[@type="text"]', value='baangt')
            self.driver.findByAndClick(xpath='(//input[contains(@type,'submit')])[3]')

That's it. All the rest is taken care of by ``baangt``. You'll also receive a nice export file showing timing information
for your TestCase.

You can subclass any other functionality, that doesn't fully fit your needs (IBAN-Generation, Browser-Handling, Timing)
and also create your own Assertion-classes (for instance if you need to receive data from a Host-System or
RFC/SOAP-Connection or any other source that is not natively supported by ``baangt.py``). Of course you'd only
re-implement methods that you need to enrich, and consume everything else from the framework.

Please consider creating pull-requests if you think some of your custom implemented functionality could be useful for
others.


``BaangtDB`` for flexible, powerful enterprise grade test automation
--------------------------------------------------------------------

Enter the next stage: ``baangtDB``. ``baangtDB`` does much more than just replace Excel as input and sequence source. BaangtDB
provides modularization of your test cases. In the above example you'd maintain the Sentry-Popup exactly ONCE for all your
test cases, where it applies.

If you're in a really large corporate environment, you'll start facing problems with the XLS-Based solution, as corporate
governance, compliance, regulations and so on will sooner or later make it difficult to use the software in this way.
Even if you use ``git`` you experience problems with different versions of the Excel-Sheets - depending on your setup of course.

But still no need invest into expensive, licensed, closed source, proprietary solutions and depend on their good will.
Run ``baangtDB`` (for testdata and testcase sequences) in a docker container, on premises or in the cloud and have the full
flexibility plus comfort for free.

To sum it up
------------

There are multiple ways to use the open source testing framework ``baangt``. Each with it's up- and downsides.

.. list-table:: Possibilities to use ``baangt``
   :widths: 100

   * - **XLSX-Simple format**
   * - to get you started the single Excel-Sheet holds test sequence and data. Fully functional, full reporting on test execution.
   * - **XLSX-full format**
   * - XLSX format: more comples test run, test sequence, test case, test steps as part of testcase definition file. Separate data file.
   * - **baangtDB**
   * - Complexity of XLSX-Format, but simpler maintenance in corporate environments. More and better ways to structure and reuse testcase sequences.
   * - **Cloud**
   * - Same as database
   * - **Hosted**
   * - Same as database