I was wondering if its a requirement to consider BDD the use of Cucumber framework or other framework of test abstraction.
I will start by answering this question.
Cucumber (or SpecFlow or any similar tool) is an implementation of the Gherkin language. Behavior Driven Development has two important components that Gherkin satisfies:
Specification by example: acceptance tests are written based on real example usage of the application.
Ubiquitous language: acceptance tests are written using the same terms and phrasing as end users will be using in their normal course of business.
Write the acceptance tests in the presence of your end users.
The Gherkin language prescribes a basic framework for writing specifications by example using the Given-When-Then syntax. Acceptance tests can be written in plain language along side your end users. These tests should be written before development begins.
This does not mean you must write those tests in Gherkin. In whatever format you choose, make sure you adhere to the three basic principals above. One useful way I've found to do this is called Example Mapping.
In Example Mapping, you take a developer, tester and someone from the product side and divide a new feature into rules. For each rule provide an example illustrating the enforcement of that rule. While you can do this with Gherkin, I frequently do this in a plain text editor without any BDD tools like Cucumber. Just record the examples any way you can. The important part is to use the same terms and phrases that the end users are familiar with. This allows the technical and product teams to communicate ideas to each other.
After that you are free to use any testing tool you want, as long as you write those tests in BDD style: use examples and the ubiquitous language. You can even use the Given-When-Then style of writing tests in plain Java. Create classes that contain methods that follow that style and include the ubiquitous language as part of the class and method names.
I'm trying to avoid having a dedicated environment for acceptance/integration/regression tests at API level (considering a microservice system has everything dockerized) always with a controlled data set for each test. Every microservice dockerized provide a default data to integrate tests.
Ideally you should be able to point your testing framework at any environment and run the acceptance tests. The reality of setting up complex environments and isolating test data from real data can sometimes prevent you from doing this. Each BDD test should create all of the data it needs to run the test. After the BDD test is finished, something should have enough knowledge to clean up that test data. This would allow you to run those tests in any environment, however you need to take care in production. You do not want to charge a real credit card when running automated tests. While a dedicated environment is not a forgone conclusion, it is not uncommon, nor is it a sign of bad design.
