Comments (4)
Sure, just get wifi on the flight :))
The reason to pick google.com is that it is a reliable site that returns 200 response code and keeps the connection alive. Another reason is that it sends a large payload in multiple chunks so we actually test that the aggregator works.
As long as we can satisfy the above, I am fine with replacing it with an RxServer.
On the other hand, I feel that not always relying on RxServer gives us more confidence that our client is compatible with other HTTP server that conforms to the standard. Same applies to RxServer. If we can have test that uses non RxClient to communicate to it, more compatible our implementation will be.
from rxnetty.
The reason to pick google.com is that it is a reliable site that returns 200 response code and keeps the connection alive. Another reason is that it sends a large payload in multiple chunks so we actually test that the aggregator works.
So, if tomorrow, for whatever reason google.com starts sending a more lighter response or stops keeping the connection alive or gives a redirect to lets says google.co.in when queried from India, we stop testing what we believe we are testing? Worst still, In the extreme case of a google.com outage (in the light of the recent instance), our test start failing?
One of the basics of unit testing is to have a predictable, consistent test case. The established way of doing so when an external interaction is required is a mock/fake. Using RxServer is achieving that mock/fake functionality. The test class in question is already using RxServer for most of the other tests. I think all the requirements you have listed is already being handled by the existing mock. Any reason why we can not use that?
Having said that, if you are more confident in using some other mocking library, that is fine too.
On the other hand, I feel that not always relying on RxServer gives us more confidence that our client is compatible with other HTTP server that conforms to the standard. Same applies to RxServer. If we can have test that uses non RxClient to communicate to it, more compatible our implementation will be.
I disagree. If we want confidence in being compatible with the HTTP spec, we should write test cases for that conformance, rather than assuming that an external server/client is adhering to the spec. By just using an external client/server we can in no way be confident that we are adhering to the specs.
BTW, I will pass on the bill to you for the WIFI in the flight ;)
from rxnetty.
It's good to move to internal implementations ... I used google.com in very early things.
We can and should simulate all server and client things we want by building clients and servers that do them.
from rxnetty.
All usages of www.google.com have been removed apart from the test HttpClientTest. testConnectException2() which is simulating connect timeout. There isn't a way to easily simulate it and hence I have left it like that.
from rxnetty.
Related Issues (20)
- Adding PipelineConfigurator in RxNetty 0.5.x HOT 1
- My async client keeps getting “Content stream is already disposed” error HOT 2
- Any plan to build RxNetty on top of RxJava 2?
- ConnectionHandler on 0.5.x-java2 branch imports rx.Observable HOT 1
- For large POSTs RxNetty seems to need to write everything before reading anything HOT 6
- ClosedChannelException while TcpClient reads from TcpServer HOT 3
- 0.5 Intuitive bytebuf handling HOT 2
- RxNetty 0.5.2 stable? HOT 4
- Create Http Client without binding it to an endpoint HOT 3
- [0.4.20] NullPointException when closing socket HOT 2
- Writes out of order when using multiple threads
- Does RxNetty support http2 multiplexing? HOT 1
- why before response.close() must response.getChannel().deregister()? HOT 2
- Unnecessary synchronised lock
- Connection Leak 0.5.2 HOT 6
- require for documentation around how backpressure works HOT 4
- HTTP POST example (REST) HOT 4
- [SECURITY] unsafeSecure() should not be used in samples HOT 1
- ResourceLeakDetector,LEAK: ByteBuf.release()
- HTTPS Server with RxNetty and existing certificate
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rxnetty.