2 Comments Thoughts about the Design Master Class - 10/13/09

So, after a lot of impatient waiting, last week my colleagues and me attended Dino Esposito’s Design Master Class, which was organized by Pieter’s new company: Sparkles.

First of all, we had a lot of fun! We had a great group and I also bumped into some ex-colleagues from Compuware which is also always amusing to say the least spacer . The food was great, each day a different experience spacer . Personally, the location was a bit too far away, but all in all I didn’t spend too much time in traffic jams so that turned out OK to.

Now let me share my thoughts about this class with you…

I don’t know if you know what topics this class covered, but you should certainly look at the table of contents before you continue reading, which you can find here.

As you’ve seen, the table of contents looks very promising and interesting, it covers all the “hot topics” on which everybody is reading and writing lately: OO design principles and patterns, unit testing and design for testability, IoC, Domain-centric design versus procedural patterns, persistance ignorance, ORM, presentation patterns, and so on…

It was a 5 day class, during which every one of these concepts was covered in depth, but in a rather theoretical context. Dino provided us with lots of examples and demo’s, but every example and/or demo only covered the specific subject we we’re handling at the moment. This provided me with a more detailed knowledge (in isolation) about these topics, but in my opinion, I missed a more practical approach.

Now, to be honest, my expectations for this class were a bit different than what we actually did (and maybe that’s just my mistake). I’ve been reading a lot about these subjects the last months (for about a year and a half now I think) and I also applied them whenever I could and the best I could. The problem with these concepts, is that they are quite “easy” to understand in isolation and to apply to simple problems, however it tends to get difficult once you’re writing a big enterprise application. That’s were the the use of all these concepts shines, but that’s also when it’s hard to apply them. You have to always keep your both eyes open in order to keep your model clean. So, in that sense, I expected we’d briefly cover these topics in theory, to finally walk through a full enterprise application, and see how these concepts are finally integrated into a complete solution. I was hoping for some pair-analysis and pair-programming sessions to compare and discuss our results in group afterwards and gain a greater insight while doing so. A little more the agile way I guess…

So what’s my final thought about this class: if your team needs to write complex enterprise solutions that require a domain-centric and object-oriented approach, this is the material you need to master to succeed. But generally speaking, I’d recommend this class to a junior developer who needs introduction to all these topics rather than to developers or architects that already have the basic knowledge and need to gain insight on how to apply them in the real-world. Gaining this insight is very hard, and I don’t doubt that it’s very hard to explain them to someone. Still I’m convinced that theory only helps to introduce the concepts, and practice is how we gain insight and refine our knowledge. There’s no silver bullet for knowing when to apply certain principles/patterns or not, there are cases in which it would be crazy to even try to apply them. That’s why I’m convinced that the only thing that can help you here is practice…

Now what’s next? I know a bunch of people who attended the Architect’s Master Class, brought by Juval Lowy last year… Pieter dit it again and will probably be organizing this class next year. I’m already subscribed to the Sparkles blog to keep an eye on this course and go whining to my boss the day registration is opened spacer !

Share it:
  • spacer
  • spacer
  • spacer
  • spacer
  • spacer
  • spacer
  • spacer
  • spacer
  • spacer
  • spacer
  • spacer
  • Categories: Courses
  • Tags: Design Master Class

3 Comments Going to Esposito’s Design Master Class in October! - 06/4/09

I’m very excited about this, so I thought I’d share it with you guys!

The Design Master Class will be held here in Belgium in October (5-9) this year. Our team just subscribed, so I can finally sleep well now: I’ll be there spacer .

I don’t know if you’ve heard about this class, so let me give you some background information. It’s a five day workshop given by Dino Esposito, one of IDesign’s trainers. The course include topics such as object-oriented principles and patterns, class design, domain-based design, persistance ignorance, and so on…

My ex-colleague Pieter Gheysens, who just founded his very own “Sparkles” was so kind to organize this course for us here in little Belgium! I’m convinced that this is one of the best courses you can attend here in Belgium, and I don’t know about you, but I’d be willing to give up attending any other events or courses to follow this one!

Just take a look at the full course details here and you’ll see what I mean! And by the way, don’t let the price tag scare you because of the financial crisis that’s going on… Remember it’s a 5-day course, and remember what it’s about. I’m sure the ROI will be worth the investment. Think about the impact of such a workshop on your team’s development… spacer

Congratulations Pieter! I’m looking forward to it… and hope to see you all there spacer

Share it:
  • spacer
  • spacer
  • spacer
  • spacer
  • spacer
  • spacer
  • spacer
  • spacer
  • spacer
  • spacer
  • spacer
  • Categories: Courses, Events
  • Tags: Courses, Design Master Class

6 Comments Introduction to test-doubles - 03/16/09

As soon as you start unit-testing or test-driving your development, you’ll learn about test-doubles and how they can make your tests lightening-fast sooner or later. And if you set up a continuous integration process (which you should) and you have more than 5 unit tests, you’ll probably have to know about test-doubles sooner in stead of later spacer .

What is a test-double?

Gerard Meszaros defines a test-double as follows:

“Sometimes it is hard to test the system under test (SUT) because it depends on other components that cannot be used in the test environment. This could be because they aren’t available, they will not return the results needed for the test or because executing them would have undesirable side effects. In other cases, our test strategy requires us to have more control or visibility of the internal behavior of the SUT. When we are writing a test in which we cannot (or choose not to) use a real depended-on component (DOC), we can replace it with a Test Double. The Test Double doesn’t have to behave exactly like the real DOC; it merely has to provide the same API as the real one so that the SUT thinks it is the real one! “

The concept is very easy to understand, but if you’ve never heard of them, I assume that how a test-double looks like, is still a blurry thing. First I have to say you have to use them with caution and only when appropriated. Apart from that, there are several types of test-doubles. You can find a list of all types in Meszaros’ book and an enumeration of them here. 

Why use test-doubles?

I think I can summarize the need of a test-double in one line: Use a test-double to keep your tests focussed and fast. If you’re doing CI and TDD, you’ll have a very big test suite after a while, and it’s critical to keep it running in a few minutes. If you don’t, you’ll end up giving up CI, and you’ll loose the continous feedback it offers you.

If your SUT depends on a component that needs a lot of setup code or needs expensive resources, you don’t want to be doing all this in a simple test. Your SUT shouldn’t care how the component it depends on needs to be configured. If you are doing it, you’re writing integration or even acceptance tests to go through the whole system… That’s why replacing a DOC object with a fake, can come in very handy sometimes. Test your SUT in isolation, that’s the goal. The DOC-components will have tests of their own. And you’ll have integration tests on top of it all.

Expectations, verifications, and stuff like that

Before I get to mocks and stubs, you need to understand the expectation-verification thing.

First of all, a mock  or a stub, is just an object that looks like the real DOC, but is actually just a fake which you can use to pass the test, or record the calls your SUT makes to it. When using such a mock/stub, you can set expectations on it. An expectation, is a statement, in which you explicitly expect a call to a particular method or property, with particular parameters, and even a particular return value. After you’ve set the expectations you consider important*, you can verify that these calls actually took place, and thus verifying that your SUT is executing what you expected.

What is a stub?

A stub is an object that you use just to get your code passing. When you don’t really care about how the interaction with the DOC-object happens, you can use a stub to replace the real dependency. A stub can be an empty implementation or a so-called “dumb” implementation. In stead of performing a calculation, you could just return a fixed value.

When you use stubs using a mocking framework, it

gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.