Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix issue #55 missing User-Agent header in API calls and issue #58 getFill API change #57

Merged
merged 3 commits into from
Mar 30, 2019

Conversation

onyxcoyote
Copy link
Contributor

Fixes issue where cloudflare blocks API requests with no User-Agent header. Based on the comment by alistairrutherford, the value of the User-Agent does not seem to matter, as long as it's present.

"Access denied | api-public.sandbox.pro.coinbase.com used Cloudflare to restrict access"

@onyxcoyote onyxcoyote changed the title fix issue #55 missing User-Agent header in API calls fix issue #55 missing User-Agent header in API calls and issue #58 getFill API change Dec 24, 2018
@onyxcoyote
Copy link
Contributor Author

Added a fix for issue #58. All the tests should be working with this pull.

#58: OrderService.getAllFills() method was removed because that request is no longer supported by the coinbase pro API. It was replaced with getFillsByProductId() and getFillByOrderId()

@irufus irufus self-assigned this Jan 15, 2019
@irufus irufus self-requested a review January 15, 2019 18:23
NewMarketOrderSingle marketOrder = createNewMarketOrder("BTC-USD", "buy", new BigDecimal(0.01));
Order order = orderService.createOrder(marketOrder);

assertTrue(order != null); //make sure we created an order
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

assertion seems redundant or possibly we need better tests for createOrder() method being called so we don't need to have assertions on preconditions which make the code look relatively untidy/big.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps a mocked response on createOrder would work here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think all the extra asserts can be removed. I was not able to get them to fail at all. Even in the case of insufficient test funds, it still returns a valid orderId (though insufficient funds causes this test and one other test to fail due to error).

The ideal situation for testing getFillByOrderId is that we have a valid orderId, which was also filled (which is pretty much guaranteed with a market order it seems). Though alternatively, it would be possible to pass in an invalid orderId and just expect 0 fills in response, which would still test the actual API call, just not the "place an Order an retrieve it's Fill" path. I'm open to trying out some other alternatives, though.

What do you think of the following?

    @Test
    public void canMakeMarketOrderThenGetFillByOrderId() { 
        NewMarketOrderSingle marketOrder = createNewMarketOrder("BTC-USD", "buy", new BigDecimal(0.01));
        Order order = orderService.createOrder(marketOrder);
        List<Fill> fills = orderService.getFillByOrderId(order.getId(), 100);
        assertTrue(fills.size() == 1);
    }

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Much nicer XD

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! This update has been committed.

Order filledOrder = orderService.getOrder(orderId);
assertTrue(filledOrder != null); //ensure our order hit the system
assertTrue(new BigDecimal(filledOrder.getSize()).compareTo(BigDecimal.ZERO) > 0); //ensure we got a fill
log.info("Order opened and filled: " + filledOrder.getSize() + " @ " + filledOrder.getExecuted_value()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't usually see log statements in tests due to them being largely redundant. If something goes wrong, the assertion should fail for the relevant condition.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will remove

+ " at the cost of " + filledOrder.getFill_fees());

List<Fill> fills = orderService.getFillByOrderId(orderId, 100);
assertTrue(fills.size() >= 0);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be >=1 ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, good point. I will change to == 1 because it should be always 1 in this situation.

String orderId = order.getId();
assertTrue(orderId.length() > 0); //ensure we have an actual orderId
Order filledOrder = orderService.getOrder(orderId);
assertTrue(filledOrder != null); //ensure our order hit the system
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe assertNotNull is available for use here (or something very similar)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will remove filledOrder entirely. It is actually not necessary.


assertTrue(order != null); //make sure we created an order
String orderId = order.getId();
assertTrue(orderId.length() > 0); //ensure we have an actual orderId
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perhaps assertNotNull works better here - so long as we get back something then we don't really care about the value?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree, will change

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correction. It looks like that can be removed. Even a failed Order still gets a valid orderId.

assertTrue(fills.size() >= 0);
}

@Test
public void createMarketOrderBuyThenGetFillByOrderId() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

naming should follow format of should do something When X happens

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about canMakeMarketOrderThenGetFillByOrderId?

The intention of the method is primarily to test GetFillByOrderId, but it ideally would place an Order first, then test getFillByOrderId.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldGetFilledByOrderIdWhenMakingMarketOrderBuy()

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh... Ok, method has been renamed as suggested.

Copy link
Collaborator

@robevansuk robevansuk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks Good! Good to merge

@robevansuk robevansuk merged commit 5300924 into irufus:master Mar 30, 2019
@robevansuk
Copy link
Collaborator

Merged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants