I have an XCTestCase subclass EndpointIntegrationTests that contains integration tests that exercise the client application's endpoints against the backend.
We have a number of testing backend environments. They share the same databases, so the tests in EndpointIntegrationTests should work equally well on all of the backends.
I'd like to be able to instantiate multiple instance of EndpointIntegrationTests in a test run, initialising each (or configuring after initialisation) with the specific backend it should test. I'd then instantiate the suite once for each backend, so that all tests are run against all backends. Perhaps a bit like this…
func addTestCaseInstances() {
for environment in ["SIT01", "SIT02", "NFT"] {
let testCase = EndpointIntegrationTests(environment: environment)
addTestCaseInstance(testCase)
}
}
Is there a mechanism in XCTest to allow this? I've only ever seen XCTestCase subclasses be automatically instantiated by the test harness. The harness only instantiates each subclass once.
Thanks.
Related
Some tests require running a database, for instance, using Test Containers Library. It obviously takes time to boot it up.
Is there a way to do this only once per entire Spek suite which spans across multiple files? The docs don't say anything about this.
Anyone knows why this has not been implemented?
This answer is not Spek-specific, but Testcontainers objects expose a simple start() and stop() method, meaning that you don't have to rely on the test framework to control your container lifecycle if you don't want to. You can create a container in a static object that is separate from your test classes, and then access it across all tests if you like.
Please see an example here (Java example snippet below):
static {
GenericContainer redis = new GenericContainer("redis:3-alpine")
.withExposedPorts(6379);
redis.start();
}
I would imagine an equivalent in Kotlin should be quite easy as an object (or similar).
How to use TestNg in Selenium WebDriver? Explain me what is the usage of that.
I am new Learner in Selenium WebDriver
Hi TestNG can be defined as
1.TestNG is a testing framework designed to simplify a broad range of testing needs, from unit testing (testing a class in isolation of the others) to integration testing (testing entire systems made of several classes, several packages and even several external frameworks, such as application servers).
2.For official TestNG documentation Please Click Here
Before you can use TestNG with selenium you have to install it first.Talking in consideration that you are working with eclipse (any version)
1.There are various ways to install TestNG either follow this or this or simply go to Help/Eclipse MarketPlace. under Find type Test NG and click on the install
now how to use Test NG in eclipse with selenium
#BeforeTest
public void TearUP(){
// preconditions for sample test
// like browser start with specific URL
}
#Test
public void SampleTest(){
// code for the main test case goes inside
}
#AfterTest
public void TearDown1(){
// thing to done after test is run
// like memory realese
// browser close
}
Some information for above code
TestNG have various annotations for more info on annotation go to the above link
#BeforeSuite: The annotated method will be run before all tests in this suite have run.
#AfterSuite: The annotated method will be run after all tests in this suite have run.
#BeforeTest: The annotated method will be run before any test method belonging to the classes inside the <test> tag is run.
#AfterTest: The annotated method will be run after all the test methods belonging to the classes inside the <test> tag have run.
#BeforeGroups: The list of groups that this configuration method will run before. This method is guaranteed to run shortly before the first test method that belongs to any of these groups is invoked.
#AfterGroups: The list of groups that this configuration method will run after. This method is guaranteed to run shortly after the last test method that belongs to any of these groups is invoked.
#BeforeClass: The annotated method will be run before the first test method in the current class is invoked.
#AfterClass: The annotated method will be run after all the test methods in the current class have been run.
#BeforeMethod: The annotated method will be run before each test method.
#AfterMethod: The annotated method will be run after each test method.
One of the primary usage of selenium is to test ui functionality, and as a testing framework testNg has many techniques to run and report the tests and can be leveraged for ui testing with selenium. One of the tools effectively use this is selion (https://github.com/paypal/selion).
I am not sure if what i am doing is actually the "correct" way of doing unit tests with DI. Right now i ask my ViewModelLocator to actually create all the instances i need, and just get the instance i need to test, which makes it very simple to test a single instance because lets asume that Receipt needs a Reseller object to be created, reseller needs a User object to be created, user need some other object to be created, which creates a chain of objects to create just to test one single instance.
With di usally interfaces will get mocked and parsed to the object which you would like to create, but how about simple Entities/ViewModels?
Whats the best practice to do unit testing with DI involved?
public class JournalTest
{
private ReceiptViewModel receipt;
private ViewModelLocator locator;
[SetUp]
public void SetUp()
{
locator = new ViewModelLocator();
receipt = SimpleIoc.Default.GetInstance<ReceiptViewModel>();
}
[TearDown]
[Test]
public void CheckAndCreateNewJournal_Should_Always_Create_New_Journal()
{
receipt.Sale.Journal = null;
receipt.Sale.CheckAndCreateNewJournal();
Assert.NotNull(receipt.Sale.Journal);
}
}
First, you aren't using Dependency Injection in your code. What you have there is called Service Locator (Service Locators create a tight coupling to the IoC/Service Locator and makes it hard to test).
And yes, it's bad (both Service Locator and Dependency Injection), because it means: You are not doing a UnitTest, you are doing an integration Test.
In your case the ReceiptViewModel will not be tested alone, but your test also tests the dependencies of ReceiptViewModel (i.e. Repository, Services injected etc.). This is called an integration test.
A UnitTest has to test only the class in question and no dependencies. You can achieve this either by stubs (dummy implementation of your dependencies, assuming you have used interfaces as dependencies) or using mocks (with a Mock framework like Moq).
Which is easier/better as you don't have to implement the whole class, but just have to setup mocks for the methods you know that will be required for your test case.
As an additional note, entities you'll got to create yourself. Depending on your UnitTest framework, there may be data driven tests (via Attributes on the test method) or you just create them in code, or if you have models/entities used in many classes, create a helper method for it.
View Models shouldn't be injected into constructor (at least avoided), as it couples them tightly
Units tests should run quickly and should be deterministic. That means you have to mock/stub everything that brokes these two rules.
The best way to mock/stub dependancies is to inject them. In the production, classes are assembled by DI framework, but in unit tests you should assemble them manually and inject mocks where needed.
There is also a classic unit test approach where you stub/mock every dependency of your class, but it's useless since you don't gain anything by that.
Martin Fowler wrote great article about that: link
You should also read Growing Object-oriented software: Guided by tests. Ton of useful knowledge.
Most of what I've read about mocks, stubs (test doubles) involves some form of injection of the DOC either through the SUT method itself or constructor or setter methods. And injecting that breaks boundaries like InjectMock are frowned upon as a regular test strategy. But what if you are building a class that you do not want to expose those DOCs? Is there a way to 'unit' test such a module? Without AOP? Is such a test not a real 'unit' test anymore? Is the resistance I'm feeling really design smell and I should expose those DOCs somehow?
For example, lets say I have the following Class that I want to test (unit or otherwise):
public class RemoteRepository {
Properties props = null;
public RemoteRepository(Properties props) { this.props=props; }
public Item export (String itemName) {
JSch ssh = new JSch();
ssh.setIdentity(props.get("keyfile"));
ssh.connect();
ssh.execute("export "+itemName+" "+props.get("exportFilename"));
...
}
Here is a unit I'd like to write a unit test for, but I want to stub or mock out the JSch component. But the objects I create in the method to just do things that the method needs to accomplish are not exposed outside the method even. So I cannot inject a stub to replace them. I could change the export method signature to accept the stub, or add a constructor that does, but that changes my design just to suit a test.
Although the unit will connect to a real server to do the export in prod, when just testing the unit I either want to stub the DOC out completely, or simulate it with a real DOC that is simple and controlled.
This latter approach is like using an in memory db instead of a real one in that it acts and behaves like the eventual db that will be used, but can be confined to just what is needed for the test (eg. just the tables of interest, no heavy security, etc). So I could setup some kind of test double sshd in my test so that when the build runs the test, it has something to test against. This can be a lot of trouble to setup and maintain however and seems like overkill - sometimes trying to stub out a real DOC is harder than just using the real DOC somehow.
Am I stuck trying to setup a test framework that provides an sshd test double? Am I looking at this the wrong way? Do I just use AOP or mock library methods that break the class scope boundaries?
To restate the basic problem is that a lot of times I want to test a method that has complex DOCs (ie. those that interact with other systems: network, db, etc) and I don't want to change the design just to accommodate test double DOC injection. How do you approach testing in such a scenario?
My recommendation, based on personal experience, is to write integration tests where DOCs (Depended On Components) are not mocked.
However, if for whatever reason the teams insists on having unit tests instead, you would have to either use a suitable mocking tool (AOP tools are able, but not a good fit here), or change the design of SUT and DOCs in order to use "weaker" mocking tools.
I have two Controller unit tests and each one sets an HttpClient metaclass execute in setUp() like the following:
HttpClient.metaClass.execute = { HttpUriRequest request ->
<return expected data for my tests>
}
Then I attempt to tear down the metaClass in tearDown() with the following code:
protected void tearDown() {
super.tearDown()
GroovySystem.metaClassRegistry.removeMetaClass(HttpClient.class)
}
However only one of my unit tests passes because the return from the HttpClient is incorrect/unexpected. If I add the logic needed for both tests in the metaClass.execute of both tests I get no testing failures. However this is cumbersome and impractical, especially in an agile development environment.
What am I doing wrong with trying to tear down this HttpClient metaclass registration? How can I troubleshoot this further?
I'm currently using grails 1.3.7 on a CentOS 5 install.
Edit: I should clarify that my problem is that the metaClass override is causing issues between test classes, not test cases. We've been setting up the metaClass override so that it will return correct data for all of the test cases in a given class. So Test class A has the metaClass data for it's test cases and Test class B has the metaClass data for it's test cases. The issue is that since Test class A gets tested first, test class B ends up using the metaClass definition from test class A and fails because of this.
You shouldn't need to implement a tearDown method. Assuming you're extending ControllerUnitTestCase or GrailsUnitTestCase If you call registerMetaClass HttpClient before you metaClass the execute method it will replace the metaClass for HttpClient in between test classes for you. I've never used the removeMetaClass method so I don't know why that wouldn't be working so I can't answer the question of why that doesn't work, but this should get you past your issue.
...
registerMetaClass HttpClient
HttpClient.metaClass.execute = { HttpUriRequest request ->
<return expected data for my tests>
}
The solution I ended up using is a bit of a hack but it's easier to maintain. I just made a class in src/groovy that creates the HttpClient.metaClass and then just made each test class that needs it run the static method on the new class. That way all of the necessary code for the meta classing is in one place.