# How to test transactions **URL:** \ **Category:** Ignition\ **Tags:** ignition81\ **Created:** [September 18, 2023, 3:25pm UTC](https://forum.inductiveautomation.com/t/how-to-test-transactions/79295 "2023-09-18T15:25:41Z")\ **Posts on this page:** 1\ **Showing post:** 6
**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\ **Post date:** [September 18, 2023, 3:56pm UTC](https://forum.inductiveautomation.com/t/how-to-test-transactions/79295/6 "2023-09-18T15:56:07Z")
Hard agree on this, a decorator is a very nice way to handle a transaction - then your business logic functions should boil down to the series of named queries you are running in a row essentially. Here's an example I've posted before about a decorator that handles a transaction and returns a GUI-agnostic response object so that you can then decide what to do with the results - > [@Script Benchmarking with Decorators Example](https://forum.inductiveautomation.com/t/script-benchmarking-with-decorators-example/63507/5): > > I made something similar to what you are aiming for but its also made for managing database transactions and errors in a standard way by creating a Response object that then I inspect after. import functools import timeit import traceback from forms2.structs import Response import java.lang.Throwable class handleTransaction(object): def \_\_init\_\_(self, logger): self.logger = logger def \_\_call\_\_(self, inner\_func): """ We do 'tx' not in kwargs a few times here. If a fucntion has tx=None… There's a few other examples as well across the forum with decorators handling transactions, and you may want to modify it for your use case, but this is the gist of it. --- _[View the full topic](https://forum.inductiveautomation.com/t/how-to-test-transactions/79295)._