![]() One of the major problems with this was the increase in the volume of data in the pre-production database, which impacted the expected outcome of our tests. The second solution was to add an identifier such as a timestamp to each data component created or updated when performing our tests in order to make the data unique. ![]() And it was out of the question for us to develop these API routes without a real functional need for them because of the security breaches this could cause. However, we were very quickly limited by the number of operations the API could perform in our application, as not all the features allowed us to run these operations on the application’s resources. Once the Cypress tests were completed, the initial data was restored with update or delete operations via the execution of API requests. ![]() The first solution was to restore datasets stored in our pre-production database via API requests. The initial contextīefore we started using the Ecto sandbox, we had two options for managing test datasets, as follows. In this article, we will focus on the benefits of this sandbox as well as the things to look out for from a QA perspective. To manage this, we chose to activate the Ecto sandbox for our Cypress tests. If developers use an Elixir and TypeScript/JavaScript stack to develop applications, on the QA side, tests are automated within the Cypress framework in a pre-production environment, with testing datasets existing in the environment database.Īs a QA team, we quickly faced a challenge encountered by all teams when they build their test automation solution: successfully controlling our environment and restoring our initial dataset in order to respect the idempotence of executions. Created in 2020, this department, among others, was established to support our fast-growing company and tech team. Don't be afraid.The QA team is still a newbie at Welcome to the Jungle. If you found this code intimidating, being comfortable with iolists both useful and important.Įlixir without Ecto isn't just possible, it's awesome. The module is easy to test, so you should a robust safety net.Īs I said earlier, you might want to look at Mobieus for something more than this quarter-baked solution. Personally, I'd suggest you start with something similar to what we've explored so far and expand it as needed. Where you take the code next is up to you. The above code captures our existing where, changes the op, executes the function, and then merges the newly generated where with the original. # first select we add shouldn't be prefixed with a commaĭef select ( % We're going to build this up slowly, starting with selecting columns from tables: defmodule A. The only thing you'll probably need is a query builder, and you can either use this post as a rough guide or use an existing tool. The goal is to let you know that it's ok to use Elixir and Phoenix without Ecto. If you're looking for that, you might want to consider Mobieus, which I've not used, but looks solid. The goal of this post isn't to provide a complete solution. This is different than Ecto in that its only purpose is to help us safely generate SQL, we're not concerned with mapping, migrations, models, callbacks or anything else. where (q, "status", :eq, user_status ) Our end goal is to be able to write code like this: q = Query. What we're going to do is leverage our knowledge of iolists to build a query builder. What about getting all users when user_status is nil? We'll need to be able to dynamically build our select statement while ensuring that we protect against SQL injections. maps! ( "select * from users where status = $1", ) For example, to get users based on their status, we can do: MyApp. One thing is obviously missing from that post: support for dynamic queries. In the last post, we looked at the basic mechanism for using elixir without ecto.
0 Comments
Leave a Reply. |