35 karma · joined February 18, 2012
ex-google, ex-banking, ex-Apple
tgpc.at.hn
Sigh.
(I also agree with the points below about the housing shortage being localised. We should do what Silicon Valley did a long time ago and move some firms to a new area.)
I have one of these: http://www.uk-automation.co.uk/products/RFXCOM-RFXtrx433.htm...
Plugged into the RPi that is running Domoticz.
Domoticz provides URLs that trigger scenes when hit.
(I'd really like to see that...)
google is pretty good about this. if you're a googler, you'll find out about most of the other things going on. there were a few exceptions during my time there (Android, Wave), but the teams involved always came clean to Googlers before they told the world. The culture is definitely very open.
my suggestion: join and find out :-)
Say you have (in this example, Java) classes A, B and C. A is public, B is public, C is package local to B.
It might make sense to test A independently, possibly with a mock B.
Then look to see if B and C can be tested together - the package local relationship suggests they may be the same unit.
There are no hard and fast rules, IMHO. If your tests are a world of pain, consider breaking things down in different ways.
Checking for a 500 sounds like it might be an acceptance test. Only hit the interface your program exposes for these!
As a worked example:
class PageGenerator { Page generate() throws ServerException { ... } }
class HttpProtocolHandler { HttpResponse handleRequest(HttpRequest req) { myPageGenerator.generate(); } }
Unit test PageGenerator. Assert that it throws a ServerException on error.
Unit test HttpProtocolHandler. Assert that if a mock PageGenerator throws an exception, the HttpResponse from handleRequest has status 500.
Acceptance test both together. Start the web server and make an actual HTTP request you know will fail. Assert that the response code is 500.
Happy to help more if you would like.