Tag Info

Hot answers tagged

3

Great question. I see two issues, as follows. Using random data may lead to unrepeatable results. You can mitigate this by logging (or otherwise recording) every random choice you make, and then playing those choices back. That could be as easy as recording the initial seed to your random number generator, assuming your data does not change over time. ...


2

You can go either way. You might include these steps in each test, because they're actions that an actual user will take. Meaning that they can potentially fail in specific circumstances, and thus you'll want them linked to that specific test case. However, signIn() and signOut() look like actions every tester will perform manually as well for every ...


2

However you obtain test data, you would like to know that it is appropriate to the intention of the tests. When the test data is defined outside of the tests themselves, there is always the chance that the data will drift away from the intentions of the tests. The chance increases if the data is maintained by someone other than the test automators. If you ...


2

To expand on bish's answer a bit: Your fixtures aren't supposed to be testing end-to-end functionality of all the subsystems - that's something for manual testing and/or automated functional testing and should be done as little as possible (because it's slow and prone to error - you do that as the top-level sanity testing). Each fixture is - or should be ...


1

Preferable you want each test to run in isolation. You don't want any artifacts of a previous test laying around. So closing the browser after each test sounds as a good thing. A test follows three steps Setup: Launch browser, setup database, etc Test: Run single testcase Teardown: Cleanup I think you can use TestInitialize and TestCleanup methods, see ...


1

Unless you have a really good reason to repeat yourself, don't. Putting in an explicit login and logout step in each test is needless repetition if every test must perform a login and logout.


1

Coming back to share a solution that I find suitable. I wrote a framework based on nose2 (a python testing framework), that allows me to write hierarchical setups and teardown, thanks to such, a nose2 plugin. start_vms test_vms_are_started configure interfaces test_interfaces configure_dhcp test_dhcp configure_nat ...



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