[OKC JUG] Reminder - meeting Tuesday, April 12th
Brett L. Schuchert
schuchert at yahoo.com
Tue Apr 12 08:25:10 PDT 2011
Well come with low expectations. Consider the context and the generalness of your request. We have around 50 minutes for a different subject than what you're asking about. Furthermore, you've not given any priority, so there's almost no chance to satisfy your request unless you have low expectations.
Regarding testing clients, this is orthogonal to using mock libraries. It's a design issue. Has the design:
- avoided DRY violations regarding accessing the layer?
- provided an interface that is domain-centric?
- made it injectable?
- ...
If so, then a test harness can set up a client using a test double for the "database". That test double should be individual-test-method focused, rather than generic for a number of test methods (more like a stub than a fake to use the terminology of http://xunitpatterns.com/). (This is the error I'd prefer to make rather than making a full simulator - aka a fake.)
Using a mock library is about how to create a test double - it's less of a testing issue and more of a test-support issue. Making something testable is a different design issue.
Now this is coming from the perspective of needing to design a solution. I use the word design loosely because this design work has already been done and there's a pretty standard way to solve it, so there's not much design left. The one thing that has changed recently for me is the design of the dao. I'd use Hades (one of the lightning talks from last month: http://redmine.synyx.org/projects/show/hades).
OTOH, if you are talking about testing the database logic:
- Use Hades - you don't write the code, so don't test it. Maybe a smoke test
- If you write it yourself and you are using an ORM, nearly same comment
- If you don't own the schema and there's heavy dependence on using the db, then you need to test with the db present
(You don't need to test the code you don't write - though it's probably worth writing some kind of smoke or integration test to verify that things actually work - it's all about risk mitigation.)
In a nutshell, that really is the essence of database testing. Really.
In general a strong separation between enabling technology and your business code is required if you want to have a chance of a well-agining system.
While I'm no fan of EJB, this is one thing they did well with EJB 3.0 spec. They removed entity beans (a complete cluster f from inception), and introduced JPA - a lightweight ORM. They made session beans POJOs and provided light dependency injection. Finally, people who had either actually written software (or at least looked at well-written software) finally got involved in writing the specs and the spec got much better. Way too little too late, but much better. Had EJB 3.0 came out about 7 years ago, it would have been relevant to modern software development.
Brett
On Apr 12, 2011, at 10:00 AM 4/12/11, Rupesh Bhochhibhoya wrote:
> I mean for all possible logic including clients.
>
> From: jug-bounces at lists.okcjug.org [mailto:jug-bounces at lists.okcjug.org] On Behalf Of Brett L. Schuchert
> Sent: Tuesday, April 12, 2011 12:45 AM
> To: jug at lists.okcjug.org
> Cc: jug at lists.okcjug.org
> Subject: Re: [OKC JUG] Reminder - meeting Tuesday, April 12th
>
> By test persistent layer, do you mean test the logic in the persistent layer, or test clients of that layer?
>
> Brett
>
> Free tutorials:
> http://schuchert.wikispaces.com
>
> On Apr 11, 2011, at 8:36 PM, Rupesh Bhochhibhoya <RBhochhibhoya at telogical.com> wrote:
>
> I have always used nice mocks. And didn't really know why other mocks didn't work well for me. So, thanks for info.
>
> Also it would be nice if you could share how to test persistent layer effectively using Jmockit.
>
> "Brett L. Schuchert" <schuchert at yahoo.com> wrote:
>
> Might as well start the talk now...
>
> When using mock libraries, by default use "nice" or "not strict" mocks. Most of them default to strict mocks. The problem with this is that doing so makes the tests more fragile and dependent on incidental complexity rather than essential responsibility.
>
> So in the case of easy mocks, don't use "createMock" by default, instead prefer "createNiceMock". Only use createMock when you really want to verify all messages sent. This is actually a fringe case when doing focused unit tests. This is typically counter-intuitive. It only becomes clear as individuals move from tests with lots of checks to focused, single-check or single-logical-check based tests.
>
> OK, discuss...
>
> Brett
> On Apr 11, 2011, at 11:05 AM 4/11/11, Rupesh Bhochhibhoya wrote:
>
>
> I appreciate if you can demonstrate examples with TDD/BDD. And also if you could show its advantages over EasyMock, that will be helpful too.
>
>
> Rupesh
>
> From: jug-bounces at lists.okcjug.org [mailto:jug-bounces at lists.okcjug.org] On Behalf Of Brett L. Schuchert
> Sent: Monday, April 11, 2011 10:52 AM
> To: jug at lists.okcjug.org
> Subject: Re: [OKC JUG] Reminder - meeting Tuesday, April 12th
>
> Oh yeah, I suppose I should prep (mostly kidding).
>
> I already have a "story" for this presentation but I'm open to adjusting if anybody has anything in particular they'd like to me to cover. Just reply to this chain with request.
>
> One thing I will be demonstrating is overriding static methods with the tool - which is cool, too cool, but cool.
>
> Brett
> On Apr 11, 2011, at 10:35 AM 4/11/11, Brian Sheldon wrote:
>
>
>
> We have a meeting tomorrow. We will be providing food and drinks this month thanks to MBO sponsoring again this year.
>
> Please go register http://okcjug.org/registration so we know how much food to get and who to pick from for the door prize.
>
> · Sponsor: MBO Partners
> · Speaker: Brett Schuchert
> · JMockit - Things you shouldn’t do when testing…
> Agenda
> · 11:30 am – Welcome Announcements
> · 11:40 am – Lightning Talks begin
> · 12:40 pm – Wrap Up
> Presentation Information
> JMockIt is a powerful and easy (perhaps too easy) to use mocking tool that allows you to do things that defy logic. Examples include stubbing static methods, changing final classes and pretty much anything that byte code injection on the fly (per test) allows. We’ll look at some of those things along with more traditional test double creation and then discuss why on the one hand it is nice to have this power, on the other hand you should almost never use it.
>
> --
> Brian
> _______________________________________________
> Jug mailing list
> Jug at lists.okcjug.org
> http://lists.okcjug.org/listinfo.cgi/jug-okcjug.org
>
> _______________________________________________
> Jug mailing list
> Jug at lists.okcjug.org
> http://lists.okcjug.org/listinfo.cgi/jug-okcjug.org
>
> _______________________________________________
> Jug mailing list
> Jug at lists.okcjug.org
> http://lists.okcjug.org/listinfo.cgi/jug-okcjug.org
> _______________________________________________
> Jug mailing list
> Jug at lists.okcjug.org
> http://lists.okcjug.org/listinfo.cgi/jug-okcjug.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okcjug.org/pipermail/jug-okcjug.org/attachments/20110412/bda3889d/attachment-0003.htm>
More information about the Jug
mailing list