655 reputation
1710
bio website
location
age
visits member for 3 years, 4 months
seen Mar 26 at 17:59

Mar
26
comment From a TDD perspective, am I a bad person if I test against a live endpoint instead of a mock?
Thank you -- I'll look into that.
Mar
25
comment From a TDD perspective, am I a bad person if I test against a live endpoint instead of a mock?
But I agree on your main point, that one shouldn't write mocks for classes they don't own. And definitely agree there's no point in writing a mock test that tests the same thing as an integration test. It would seem mocks are best for testing interfaces/contracts. Thanks for the advice -- this has helped me a lot!
Mar
25
comment From a TDD perspective, am I a bad person if I test against a live endpoint instead of a mock?
I suppose I could create a nice, friendly wrapper class for HTable that took care of all that housekeeping, but at that point ... I feel like I'm kinda building a framework around HTable, and should that really be my job? Usually "Let's build a framework!" is a sign I'm going in the wrong direction. I could spend days writing classes to make HBase more friendly, and I don't know if that's a great use of my time. Plus, then I'm paasing around an interface or wrapper instead of just the plain old HTable object, and that would definitely make my code more complex.
Mar
25
comment From a TDD perspective, am I a bad person if I test against a live endpoint instead of a mock?
I agree with most of your answer. However, I'm not sure I agree about the Adapter part. HTable is a pain to mock because it's fairly bare-metal. For example, if you want to do a batch get operation, you must create a bunch of Get objects, put them in a list, then call HTable.batch(). From a mocking perspective, this is a serious pain, because you have to create a custom Matcher that examines the list of get objects you pass to HTable.batch() and then returns the correct results for that list of get() objects. A SERIOUS pain.
Jul
22
comment What are some best practices for populating and using a test database?
Okay, thanks! I'm going to continue looking into this. Any other tips for using DBUnit?
Jul
22
comment What are some best practices for populating and using a test database?
Okay, took a look at DBUnit. It seems like the tool is most geared towards doing an export from your actual DB to XML, and then consuming the XML with DBUnit. Does that sound right? Because otherwise, you'd be stuck updating your XML every time you update your database schema, which would be a major pain.
Jul
21
comment What are some best practices for populating and using a test database?
Also, is it necessary to use DI for this? Right now I have a persistance.xml in my /main/resources/META-INF folder that specifies my acutal DB server, and a persistance.xml in my /test/resources/META-INF folder that specifies H2. This seems to work really well. In general, I'm super-ultra-100% confused about Spring -- I've never used it before and don't understand how it could help me here, even though everyone says I should use it.
Jul
21
comment What are some best practices for populating and using a test database?
Awesome! Okay, I'm going to check this out.
Jul
21
comment What are some best practices for populating and using a test database?
Well, I should mention that I'm new to Hibernate. So it actually is important for me to test that I've done all my hibernate stuff correctly. Also, it seems like a lot of operations couldn't be tested with a mocking framework. For example, you have a method that returns a bunch of records. How can you test that method actually returns a bunch of records if you don't have a database for it to run against?
Jul
21
comment What are some best practices for populating and using a test database?
Cool -- I'll definitely check that out. Right now, I'm telling Hibernate to auto-create the tables, using the hibernate.hbm2ddl.auto=create-drop property. Will that work with DBUnit, or should I stop doing this?
Jul
21
comment What are some best practices for populating and using a test database?
Yes, I already use Mockito for unit tests. But I also want to do (integration?) tests that reach out to the DB.