Hot answers tagged

9

I recommend One set of tests You've clearly defined a common problem that many of us face. I have tried all of the solutions you outlined but they all seem to run into the issue of a lot of maintenance and knowledge and updating code based on environment. My recommendation is one set of tests. If there are dependencies, e.g. database you create a connection ...


3

Testing APIs is potentially endless, just like almost anything in testing. I recommend focusing on one area rather than drowning yourself in something completely new. That would be a recipe for failure. If you're completely new to the world of APIs, I recommend installing Postman (or any other client) and playing around with some endpoints for a bit. No need ...


3

You can create have multiple implementations of your client object. import abc class MyServiceClient(abc.ABC): @abc.abstractmethod def get_item(self, id): pass class MyServiceClientStub(MyServiceClient): def get_item(self, id): return Item(1) class RealMyServiceClient(MyServiceClient): def get_item(self, id): # ...


2

If I'm not mistaken, usefixtures can't be used in this way, that is to return values to each of your test methods. You'd use this for like cleanup tasks like in the example here. For what you're asking about, you'd need your fixture as a parameter: class TestConf: def test_conf_test1(self, get_config_values): print(f"Test for user a") ...


2

I work in an environment where we have many environments but they're all part of a single release pipeline, i.e., features are first deployed to dev and they progress through all environments until they reach production. I can imagine some organisations might have different environments that are connected to different downstream systems, which possibly ...


1

self.driver means driver of this object and your code cannot find any variable called driver for that object instance. There is no instance variable driver: def test_e2e(self): action = ActionChains(self.driver) do something like (if baseclass has a driver class variable) from utilities.BaseClass import BaseClass driver = BaseClass.driver This ...


1

When I first started out in Technical Operations I would run SQL scripts to verify the ETL processes we had running. Now that I had experience in SQA I would more likely write some unit tests so its easy to tell what failed using the reporting tools or the test runner(s). You could create unit tests in SQL Server. You could also create unit tests in Visual ...


1

I'd also take into account how much code the "creating new user" part is. In pytest/Python, it really boils down to just one line of code, something like: response = requests.post(f"{Config.base_url()}/create_user", headers=headers, json=user_body) So the question is whether or not it's worth it creating a new fixture for only one line ...


1

You can also use x-unit style for setups and teardowns: class TestSetupTeardownExample: @classmethod def setup_class(cls): print("setup class") @classmethod def teardown_class(cls): print("teardown class") def setup_method(self, method): print("setup method") def ...


1

This is a common trap people fall into when writing behavior driven tests. You do not want to run entire scenarios as a prerequisite. Instead, you need to write one or more Given steps that simulate the things the other scenarios do. Without seeing an example of the login scenario, and one of the other scenarios requiring the user to log in I cannot give you ...


1

You've probably figured this out already, since you posted the question two months ago. But just in case, and for the benefit of anyone else who has the same question... PyTest's approach to supporting the parameterized test case design pattern is using what they call "fixtures". Fixtures are also used for the same purpose as TestNG's @Before* and @After* ...


Only top voted, non community-wiki answers of a minimum length are eligible