Vision

Version 1.0.0 - Initial release

Balta is pretty mature already, and there are just few touches needed to make it ready for 1.0.0 release.

Cleaning the documentation

The documentation is not very exhaustive at the moment. There are some parts that need to be expanded, and some that need to be re-written for better clarity.

Turning AllowedTypes into type class

The current implementation of AllowedParamTypes is based on sealed trait and enclosed implicit objects. This works, protects the queries well, but is not very extensible. Using type classes would allow users to extend the supported types more easily.

Ability to create stub functions

The ability to have stub functions within Balta tests would simplify the creation of test cases. Stub functions would return predefined results, without executing any logic or requiring underlying data. This would be particularly useful for testing complex queries that depend on multiple functions, allowing to isolate and test specific parts of the query logic.

As functions re-/creation is part of the transaction, therefore the code change is only temporary for the test case scope.

Two possible modes of usage come to mind (they can exist together):

• Scala idiomatic - to create such a stub the name of the function name with input parameter types would be required and the return values of the function (or a sequence of results for a set returning function). The code of the stub function would be generated automatically.
• SQL (source) based - the user would provide the full code of the stub function. This would allow to create more complex stubs, e.g. with conditions or other logic within.

Advanced feature would then be to add tracking of the calls to the stub functions, so that the test case can verify that the function was called with expected parameters, and expected number of times. The input values would be inserted into a temporary table via an injected code snippet within the stub function. Later they could be retrieved and verified within the test case using newly created functions in DBTest class.

• The temporary table suggested structure:
  • function_name (text)
  • call_index (int) - to be able to distinguish multiple calls within the same test case
  • parameter_name (text) - nullable for functions without parameters
  • parameter_value (text) - nullable for functions without parameters
  • parameter_type (text) - nullable, to be able to parse back the value when reading
  • parameter_index (int) - to be able to keep the order of the parameters, 0 for functions without parameters
• For recording the call a temporary function is suggested to be created (next to the table)
  • taking in the
    • function name
    • parameter name
    • parameter value in text form
    • parameter type
    • index of the parameter (0 for functions without parameters)
  • the call index is determined automatically within the function
    • if index of the parameter is 0 or 1 take the coalesce(maxcall_index + 1, 1) as new call index
    • else take the max(call_index) for the given function name

NB!: The tracking feature would be more complicated to implement in the source based stubs:

• the input parameters would need to be provided separately, like in the scala idiomatic mode, or parsed
• the recording function call would need to be injected into the provided source code of the stub function
  • for pl/pgsql this would be relatively straightforward
  • for sql language using WITH would solve it
  • other languages usually have an execute function
    • pl/v8: plv8.execute("SELECT * FROM my_table WHERE id = $1", [id]);
    • pl/ruby: PlRuby.execute("SELECT * FROM my_table WHERE id = $1", [id])
    • pl/python: plpy.execute("SELECT * FROM my_table WHERE id = $1", [id])
    • etc.

Better directing to error source

When a Balta test fails it doesn't provide the best information about the source of the error. Better integration with ScalaTest's reporting capabilities would help a lot. The idea is to be able to point to the exact line within the test case code where the failure happened, not just within the Balta library code.

Support of behavioral testing (The FlatSpec style)

Balta currently supports only the FunSuite style of ScalaTest. Adding support for FlatSpec style would allow users to write tests in a more behavior-driven way, which can be more readable and expressive.

Access rights testing

Testing the logic of the function is essential. But it would be great if Balta would be also able to verify the access rights of the function as well. Having a function in DBTest that would do that would be very useful. In the background it would query the database catalogue and verify that the specified DB function (whole signature) has the expected access rights.

Extracting the basic commons into a new library (Mag)

There are a number of capabilities within Balta that are generic enough to be extracted into a separate library. As they are used in Fa-DB and Ultet as well. It would make sense to have them in a separate library that these projects can depend on.