logs archiveIRC Archive / Freenode / #php / 2015 / August / 22 / 1
lenswipe
hey guys
I'm trying to write unit tests for a REST client I'm working on, could someone point me in the direction of mocking HTTP backends?
laszlof
lenswipe: theres a ton of packages out there that do that
caffinated
the most important part is that you separated your HTTP interface enough that it can be mocked
lenswipe
caffinated, im currently in the process of building the client so that's somewhat in flux at the moment
laszlof, and I'm asking if you can name a few(in PM if need be)
caffinated
generally if you're using proper dependency injection, and you've got your interfaces nailed down it's not too hard
lenswipe
im not currently using dependency injection
caffinated
instead of passing in the live HTTP object, you pass in your mock object
lenswipe
but since the library is in very early stages, i could be
caffinated
it's probably not a bad idea
at least make that part an attribute that you can overwrite
         

lenswipe
well i do a lot of angular work and i love it...just not sure how to do it with PHP
undrinkablesoup
Sammitch: Each one only appears once. But... I can't believe whatever underlying mechanism does the lookup doesn't cache itself.
caffinated
lenswipe: it's not too hard. just instead of instantiating in a way that makes the object impossible to replace on the fly, create a system that makes it easy to replace on the fly.
one of the harder parts of testing is understanding how you can write your code so that it's more easily testable in isolation
NoiseEee
undrinkablesoup: what about running a CRON that does the host lookups and stores them in a DB to be retrieved as part of a JOIN w/ the query you're using now?
caffinated
this usually means you have a good idea of an object's dependencies, and a way to replace them all with things that emulate predictable responses
then you can do things like verify that a mock obeject was called the appropriate number of times, and recieved the appropriate input signature.
the response of course will just be predefined (the object won't really do any real work)
lenswipe
caffinated, can i show you what im trying to do so you can sort of apreciate what im getting at
caffinated
sure
lenswipe
caffeinatedcode, https://github.com/robertmain/communique/blob/master/src/Communique.php
that's the class I want to write tests for and I need to provide a fake backend to use in _call
caffinated
so, the first thing to keep in mind here is that you're limiting your options when you make a dependency private
you can get around that, but it's more work than allowing some kind of direct or controlled replacement
I also see direct instantiation of your client as a static class
for example: private function _call($request){ return new \Communique\RESTClientResponse(200, 'BOOM!'); } is going to be hard to mock
when you test, you want to test in units. this usually means one class at a time, with each test checking a functional aspect of one method of that class.
lenswipe
caffinated, that instantiation is just an example just now
caffinated
ok
testing this won't be too hard once the dependency is decoupled
lenswipe
are there any more?
or just that
_call is private because there will be public methods for get, put, post and delete
caffinated
the rest of it seems to just be request/response wrappers for now
lenswipe
pretty much
and exceptions
caffinated
so there isn't too much I can suggest. It seems like a reasonable start
lenswipe
ok, cool
im going to start by adding a real cURL class and maybe go from there in mocking it out?
caffinated
well, in testing you'd usually write your tests first and then write code to make your tests pass. though, there's some philosophical disagreements about the procedure.
more important than when you write your tests is that you are writing tests imo
runinsquares
caffinated, you use phpunit?
caffinated
so depending on who you talk to, you may find people advocating tests before code, or you may find people who say code before tests
runinsquares: I have used it in the past, yes
most of my new projects are not php-driven.
runinsquares
good choice
         

caffinated
that shouldn't be seen as an endorsement of the idea that projects shouldn't be written in PHP though.
write your projects in what you think they should be written in imo
ghnubst
close
lenswipe
caffeinatedcode, im currently doing both side by side
...although right now im trying to the groundwork for both sorted out
caffinated
yep, the initial architecture is something I always find to be the slowest part
it's so easy to second guess your ideas, and come up with a multitude of "what ifs"
my last project I scrapped 3 times before I decided on the base
runinsquares
sounds tiring
caffinated
I think you should not be afraid to throw out early code if it's not meeting your expectations
NoiseEee
meh
start monkeypatching early!
jk
caffinated
haha
lenswipe
yeah but its just that process of my mind going in circles at like 10000000000 miles an hour trying to figure everything out :p
caffinated
MORE DIRTY WORDS HAVE NEVER BEEN SPOKEN
lenswipe
im buidling this as a personal project to be released on composer and then included in a work project
caffinated
lenswipe: use paper. try to visually depict flow
this can help a lot
lenswipe
currently we have a REST client at work that everyone is using that breaks if you try to send non scalar values accross
caffinated
I find that when i work from the highest level, to the lowest level, it tends to work better for me
meaning, work from the end users perspective backwards
so in the case of an API, I start by listing all the things someone consuming the API would expect
this ultimately morphs in to my requirements documentation
lenswipe
caffinated, good point! thanks!
(Action) bribes caffinated with coffee
caffinated
TOO LATE. you have to catch me in the morning. An hour after work has started the caffeine drip never stops!
Alphos_
hence the nickname...
runinsquares
for some reason you're making me think of chocolate covered coffee beans
not had them in years, they're delicious
i guess because i've been craving dark chocolate today
xernus
Hi! I often read that when storing IP addresses one should inet_pton and inet_ntop - I get that people recommend that. But I can't seem to find any explanations on WHY this is a good idea and what the benefits are. E.g. querying it seems harder? Anyone who can elaborate on that?
pEYEd
xernus: it's faster
one less step/calculation.
xernus
pEYEd: Indexes work faster on the binary data too?
Alphos
xernus storing the IPs as strings takes more space as they're stored as ASCII (1byte/char, minimum of 7 since the dots count) instead of 32-bit integers (4 bytes total)
pEYEd
xernus: parsing from string to binary is a longer road than you think, to travel. Especially in the networking world where you 'never' cross layers.
Alphos
xernus additionally, when you'll get to taking masks into account, searching for A.B.C.D/n is incredibly easy if the ips are stored as integers, incredibly tricky if they're stored as strings
xernus
Alphos: Yeah, but storing as int's are ip2long, not inet_pton or am I missing someting here?
Alphos
xernus the only difference between ip2long and inet_pton is the php type they return. they will return the same binary value, except one is an integer while the other is an integer
one is a STRING while the other is an integer
but they'll be the same bytes ;)
xernus
Alphos: Okay, So to put the last nail in the coffin. If I store e.g. 10.0.0.2 and 10.0.0.5 as binary. And I want all ip addresses between 10.0.0.1 and 10.0.0.255 - then when storing as int's it'd simply search between 2 ints. How would I do that if I store them as binary?
Alphos
store them as ints
same bytecounts, except one is easy to handle
xernus
How about IPv6?
Alphos
ymmv, of course
xernus it gets a bit more complicated, since they're 128-bit values, which means your system can't handle them as integers. in this case, you may want to either store them as binary strings, or as string representations of integers. i never had to handle ipv6, so i wouldn't want to advise one or the other, but they are your two options
xernus
Alphos: Okay, thanks for your explanations so far. I'll go on and read some more, see if I can come to a conclusion and make a decision :D
Alphos
xernus feel also free to ask in the channel that supports your dbms
lenswipe
caffinated, do i need to provide a namespace for type hinting?
Alphos
in my current, migrainous and drunk state, i'd prolly go for the dirty decimal string representation of a 128-bit integer, but i'm guessing your dbms has functions to handle them as binary
« prev 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 next »