Cannot spy on Titanium.Network methods with Jasmine - testing

I'm using Jasmine to write tests for a Titanium project. I have a custom util js to provide me information about the network availability.
In this util there is a helper method calling Titanium.Network.getNetworkType() to retrieve the current active network type. The action I do depends on the network type retrieved by this call. To ensure test coverage on this, I'm writing Jasmine tests. But unfortunately I'm having issues with spying on Titanium.Network.getNetworkType()
Code snippet:
console.log(Titanium.Network.getNetworkType()); // returns 1
spyOn(Titanium.Network, 'getNetworkType').andReturn(666);
console.log(Titanium.Network.getNetworkType()); // returns 1
Spying on a method of Titanium (e.g. getApiName()) does work. Any ideas on this?
Thanks.

Related

Tests retrieved from collection variable - test failures stop subsequent tests from running

I have tests that I want to use in multiple API calls.
Using JavaScript from external files has been an open issue for 6 years now but isn't officially supported (yet). I'm storing tests in collection variables so they can be retrieved in each APIs Tests.
The issue is tests that fail stop execution like a general JS failure.
Tests being stored in collection variables via an API’s Pre-req
In a setup API call I store the shared library of tests via a Pre-request Script. This is working fine.
A "normal" test failure
When a test is coded in an API's Test area, failures don't stop subsequent tests from running.
A failure for a test pulled in from a collection variable
I can pull tests from the collection variable and run them just fine. However when a Chai expectation fails it seems to be treated like a JavaScript failure instead of an test/expectation failure.
The test run fails, subsequent tests for this API don't run nor do other APIs in the collection run.
How can I have tests retrieved from a collection variable run/fail like hard coded tests?
Problem I guess is how you call function from utils
Just utils.payloadIs204, not utils.payloadIs204()
And it works for me
Update reuse with passing parametes.
Tab pre-request
pm.environment.set("abc", function print(text1, text2){
console.log(text1)
console.log(text2)
} + "");
Tab Test
let script = pm.environment.get("abc");
eval((script + "print('name', 'age')"))
The problem was in how I was calling the library function. It works as desired if the library function (with the expectations) is invoked in the anonymous function passed to pm.test(), not be the passed function.

Cypress tagged hooks with mocha

I have been building ui automation frameworks with Cypress for some time, but always using the Cypress-Cucumber-Preprocessor.
Now I need to build one without cucumber, just plain ol' mocha, but I found a problem. Seems like I can't use tagged hooks to execute code for specific tests (scenarios in Cucumber)
The scenario is basically this. I have a spec file with several tests. I have a "before" hook that seeds test data to a Mongo db, and eventually I might need to add a hook or hooks to execute something (whatever) before a specific test.
With Cucumber you have a way to tag a given scenario (#tag) and then you can create a hook that will be executed ONLY before or after that specific scenario
#tag
Scenario: Tagged scenario
Given condition
When I do this
Then I should see that
before({tag : '#tag'}, () => {
code
})
I haven't found a way to do this with mocha in Cypress... Anyone has found a way?
thx
You can use BeforeEach or Before, that does predominantly the same thing in Mocha.

Properly testing an SDK that calls an API

I have an API that I've written and now I'm in the middle of writing an SDK for 3rd parties to more easily interact with my API.
When writing tests for my SDK, it's my understanding that it's best not to simply call all of the API endpoints because:
The tests in the API will be responsible for making sure that the API works.
If the SDK tests did directly call the API, my tests would be really slow.
As an example, let's say my API has this endpoint:
/account
In my API test suite I actually call this endpoint to verify that it returns the proper data.
What approach do I take to test this in my SDK? Should I be mocking a request to /account? What else would I need to do to give my SDK good coverage?
I've looked to other SDKs to see how they're handling this (Stripe, Algolia, AWS), but in some cases it does look like they're calling a sandbox version of the actual API.
(I'm currently working with PHPUnit, but I'll be writing SDKs in other languages as well.)
I ended up taking this approach:
I have both unit tests AND integration tests.
My integration tests call the actual API. I usually run this much less frequently — like before I push code to a remote. (Anyone who consumes my code will have to supply their own API credentials)
My unit tests — which I run very frequently — just make sure that the responses from my code are what I expect them to look like. I trust the 3rd party API is going to give me good data (and I still have the integration tests to back that up).
I've accomplished this by mocking Guzzle, using Reflection to replace the client instance in my SDK code, and then using Mock Handlers to mock the actual response I expect.
Here's an example:
/** #test */
public function it_retrieves_an_account()
{
$account = $this->mockClient()->retrieve();
$this->assertEquals(json_decode('{"id": "9876543210"}'), $account);
}
protected function mockClient()
{
$stream = Psr7\stream_for('{"id": "9876543210"}');
$mock = new MockHandler([new Response(
200,
['Content-Type' => 'application/json'],
Psr7\stream_for($stream)
)]);
$handler = HandlerStack::create($mock);
$mockClient = new Client(['handler' => $handler]);
$account = new SparklyAppsAccount(new SparklyApps('0123456789'));
$reflection = new \ReflectionClass($account);
$reflection_property = $reflection->getProperty('client');
$reflection_property->setAccessible(true);
$reflection_property->setValue($account, $mockClient);
return $account;
}
When writing tests for the SDK you assume that your api DOES work exactly like it should (and you write tests for your api to assure that).
So using some kind of sandbox or even a complete mock of your api is sufficient.
I would recommend to mock your API using something like wiremock and then write your unit tests around that mock API to make sure everything works as desired.
This way when your production app with break, you can at-least make sure (by running unit tests) that nothing broken in your application side but there can be problem with actual API (i.e response format being changed).

How to write Java code using ther Jubula client API

I am new to the testing environment and have been searching for tutorials on Jubula client API.
Fortunately I have managed to find one, but still I am unable to launch my project. Till now I have installed the JUnit plugin in Jubula and configured the AUT on the standalone. Am I supposed to straight away make the JUnit unit test class or something else has to be done?
There is an FAQ on the Jubula Testing Portal about this:
http://testing.bredex.de/faqs/jubula-api-setup.html
You need to connect to the AUT first and map the objects from the app accordingly for usage and launch the test application.
Assign the variables or objects from the Swing or HTML and perform the required testing according to need.
For example:
public static final ComponentIdentifier btnFileExit = MakeR.createCI(Object from Jubula); //$NON-NLS-1$
Now, perform the required actions on the application and webpage, respectively.

Accessing synchronous behavior via a Protractor instance

I would like to inject a protractor instance into my tests, and then use this to perform navigation and element selection, but it appears that the functionality hanging off the Protractor object is all asynchronous, and the functionality on browser and element is synchronous.
Is there a way to access the synchronous behavior via the Protractor object?
Also: I have seen tests that invoke the following at the start:
protractor.getInstance()
...and I have seen tests that use the globally available browser and element objects directly.
What are the important differences between these two approaches?
Nothing in protractor is synchronous. It just looks that way before jasmine has been patched (by jasminewd) to wait for the async code so that it's easier to work with.
Please read https://code.google.com/p/selenium/wiki/WebDriverJs to see how controlflow makes everything in webdriver look synchronous. Then read https://github.com/angular/protractor/blob/master/docs/control-flow.md to see how protractor did it with jasminewd.
The link shared by #glepretre (stackoverflow.com/q/25496379/3049002) tells you the difference between ptor.get and browser.get. In short, use browser.get()