4 ms·
Yep, any time I have an assumption about how code should work, that's a good starting point to write a test. Even if it's vaguey like "should not throw when giv
by lfowles 11y ago
Yep, any time I have an assumption about how code should work, that's a good starting point to write a test. Even if it's vaguey like "should not throw when given inputs X Y Z that I expect will be encountered"
- crdoconnor 11y agoThat's kind of a waste of time if you're only going to run it once and verification with a REPL or otherwise by hand is easy enough.
- lfowles 11y agoThat's assuming it works correctly the first time (I haven't had that experience often, even for "trivial" code :( ). Even for "run once" functions, I still use a few tests to develop them and make sure my expectations are correct. With a good framework, setting up a handful of unit tests takes just about as much dev time as running the function in a REPL.
- crdoconnor 11y agoOk, so let's say you were experimenting with the selenium library to see if you could scrape what comes out of skyscanner. What steps would you take?
- lfowles 11y agoI'm not clear on what the scope of selenium is or how it works, but for a general web scraper, I'd identify some targets I want out of skyscanner. Here's a quick googletest butchery for "I want to make sure my function returns flights for a known good flight search." TEST(SkyScanner, ListFlights) { flights = MyFlightScrapingFunction(LAX, AMS, date+1 month, 1 way, 1 adult) EXPECT_THAT(flights, SizeIs( Gt(0) ) EXPECT_THAT(flights, Each( AllOf( Field(&Flight::from, Eq(LAX)), Field(&Flight::to, Eq(AMS)), Field(&Flight::seats, Eq(1)) ))) } I feel that anything simpler ("is this possible with selenium?") is a documentation moment.