marionette VS dotnet-testcontainers

I've been doing some promoting of my side project by responding to posts/comments that are relevant with details about my project, but I don't know how often questions about what kind of automation frameworks there are come up. I told my coworker about your project after tracking it down, it sounds like it may be somewhat similar to something we homebrewed and we can possibly make use of https://github.com/asimmon/askaiser-marionette instead.

About a year ago, I started writing this test automation framework which is based on image and text recognition. Now that I've done quite a lot of testing and polishing, I've reached the point where I'd like to receive feedback from QA and software engineers. This is why I am asking for your help today:

So, give it a try, and take a look at the sample project! It only works on Windows, because screen capture, mouse and keyboard interaction are only implemented for that OS so far.

So what I usually do is: • Unit test underlying (public) services and application ‘core’ • Integration test (or w/e you call it) an entire functionality flow, by sending in ‘real’ requests on one end, and locally mocking/stubbing the application ‘edges’ that supply the response data. WireMock for requests to external services, H2 or Testcontainers for database.

I'd use testcontainers to spin up an instance of Progress and run against the actual thing. That way you get the benefit of testing against the actual database, but also that you don't have to set up a bunch of stuff locally.

Not every db support array as primitive, if you want to write integration tests and you have access to docker I suggest you testcontainers.

There is a rope which can help with this task: https://github.com/HofmeisterAn/dotnet-testcontainers

Dotnet.Testcontainers also comes with some built-in classes that wraps various services, one of these classes actually wraps a SQL Server Docker container and there are few more that covers the most common databases e.g.

You should also check out Docker, especially TestContainers. That way you can spin up databases (and other dependencies) on the fly and do operations on them. This means that you don't need to "fake" a database, as you will have access to a new one.