Objects Dependancies Are Their Own Tax

This list of ways one class can depend on another is ordered from worst to best (for C++):

1. A depends on B because B is Singleton.

Avoid this. The dependency is 'invisible' and Singleton makes it worse than a global variable. Destruction is usually not possible unless a counting mechanism is used.

2. A depends on B because B is global variable.

Avoid this. The dependency is 'invisible'.

3. A depends on B because B is a file-local variable.

Avoid this. Not accessible to test.

4. A depends on B because B is a function-static variable.

Avoid this. Initialization is not multiple-thread safe. Not accessible to test. Destruction is difficult.

5. A depends on B because B is a class-static variable.

Avoid this. A class with static members and non-static members is doing two things. Separate the two responsibilities into separate classes, one of which can be a longer-lived than the other.

6. A depends on B because B is a member variable of A "by value".

Great for "value" objects, not so good for other kinds of objects. ("By Value" means by not by pointer nor by reference,)

7. A depends on B because B is a local variable of one of A's function.

Inaccessible to test. The dependency is 'invisible'.

8. A depends on B because B is a "by value" parameter in A's functions.

Not subject to faking or mocking, any data or behavior that are defined in a subclass of 'B' is "sliced-off" to be just a "B" inside the function.

9. A depends on B because B is a pointer/reference member of A, created in constructor.

Creation in the constructor is too soon for us to insert a fake.

10. A depends on B because B is a pointer/reference member of A, created in non-virtual function.

We can't override the creation inside the function.

11. A depends on B because B is a pointer/reference member of A, created in virtual function.

This allows us to override the function that creates B, using a fake, stub, or mock.

12. A depends on B because B is a pointer/reference member set by parameter in A's constructor.

We can create A with a fake, sub, or mock in testing. Dependency is visible.

13. A depends on B because B is a pointer/reference parameter in A's functions.

This makes the dependency visible in the interface. We can supply fake, stub, or mock in testing.

Coupling. Or... what you don't want your objects doing too much of.

Dependencies by one class on another class can cause problems when refactoring and writing microtests. In microtests, you want awkward collaborators to be faked, mocked, or stubbed out, and some kinds of dependencies make that more difficult than others.

Here are some dependencies from best (least-coupled) to worst (most tightly-coupled).

1. Class A depends on Class B, where class B is an interface ("pure" abstract base class).

We can test instances of A by creating our own test-specific subclasses of B to pass into A.

2. Class A depends on Class B, where class B is a concrete class but the functions are declared virtual.

We can test instances of A by creating our own test-specific subclases of B, but at a price: we have to deal with B's constructors and destructor, possibly doing stuff we don't want.

3. Class A depend on Class B, where class B is concrete class with no virtual functions.

We're going to need to refactor B and/or A for testability. Either making B's functions virtual, or putting an testable Adapter between A and B.

4. Class A depends on Class B, and class B grants class A "friend" access.

Class A not only depends on the public interface of B, but also the private parts of B as well. Not recommended. Don't do this unless you are Bjarne Stroustrup. If a test needs to access private parts of B, make those parts 'protected' and use a test-specific subclass to change selected parts of B to have 'public' access.

5. Class A depends on Class B, and class B is a class declared INSIDE class A.

This can lead to mutual complete visibility between A and B, plus the scoping makes it hard to test A without B, or vice versa. Not recommended. Don't do this unless you are Alexander Stepanov.

Also affecting how class A depends on class B is the WAY the dependency is manifest. It turns out that "visible" dependencies are often better than "hidden" dependencies, which is opposite of the usual idea of "information hiding", the predecessor idea of "encapsulation".

from one twitter-reading session

Stuff I found interesting in reading twitter today, mostly links to things I'd want to read later.


RT: @LeanVoices: The idea is the easy bit, execution is where excellence and hard work resides.

RT: @suziedwards: Resume blooper of the day? "Software Mythologies used include Waterfall and Scrum".

RT @markrneedham: How to type on an iPad http://bit.ly/ftr9Vl

RT @flowchainsensei: Facebook's data center play sidelines Google, Apple http://reg.cx/1NBh

Chad Fowler = "These have changed my developer life, how I perceive software
and that great technology is fun" http://bit.ly/hP2B6O

Cool, @gregturn has finished Python Testing Cookbook! #congrats http://www.packtpub.com/python-testing-cookbook/book

RT @hackernewsbot: New engine shakes up auto industry... http://www.msnbc.msn.com/id/42460541/ns/technology_and_science-innovation/

Divvy is pretty awesome. http://bit.ly/g11Hj5

RT @badbanana: If you enjoy being the 10,000th person to put your thumb into a hole, then bowling is for you.

RT @theCoachingblog: "The things we hate about ourselves aren't more real than things we like about ourselves."
(Ellen Goodman) #quote

"Managing" Velocity: The term velocity is very well-chosen. It means speed in a certain direction, w... http://bit.ly/gvikOP #agileotter

RT @capotribu: "My startup story: from big idea to thriving business in 8 short years" http://t.co/IXMCjfV < great story of real reality

Fun Fact http://dinosaurmusings.wordpress.com/2011/04/08/fun-fact/

Our schools failed many of us. Why don't people understand the role of analogy? http://bit.ly/gBRqji (see comments) #testing

Good read. RT @toddcharron: An Agile Pace http://t.co/Rn9Gzuf - reminds me of http://t.co/gwmGRX7 #agile #scrum #kanban #overtime

Best #Agile article this year: Agile’s Second Chasm (and how we fell in) http://bit.ly/hvQDpT by @williampietri #recommended

RT @tottinge @jamesshore Someone was selling us a product that allows you to "collaborate in isolation from each other."

James Shore = For the record: Rabu is not and never* will be a project management tool, a planning tool, or a replacement for a whiteboard.

See what you started, mike hill? RT @alancfrancis: I am now nekkid as a jaybird, in an apartment with 10 windows wide open, attempting to cool down. #sorrytoputthatimag ...

10 Acts of Resistance That Changed the World — YES! Magazine http://t.co/NFN2UVx

jasonlittle = we did a retrospective on why we stopped doing retrospectives. good insights, blog post coming.

I read this = http://blog.benjaminm.net/2011/02/16/argyriscasestudylearningmodelii/ = worth it

http://blog.benjaminm.net/2010/12/07/agile-argyris-double-loop-learning/

publishing co I never heard of: http://www.packtpub.com/python-testing-cookbook/book

This practical cookbook covers lots of test styles including unit-level, test discovery, doctest, BDD, acceptance, smoke, and load testing. It will guide you to use popular Python tools effectively and discover how to write custom extensions. You will learn how to use popular continuous integration systems like Jenkins (formerly known as Hudson) and TeamCity to automatically test your code upon check in. This book explores Python's built-in ability to run code found embedded in doc strings and also plugging in to popular web testing tools like Selenium. By the end of this book, you will be proficient in many test tactics and be ready to apply them to new applications as well as legacy ones.

http://www.ted.com/index.php/talks/jonathan_haidt_on_the_moral_mind.html

yourmorals.org ?

https://github.com/twitter/commons

engineering.twitter.com blog = Cross-site Scripting Protection is one hundred percent live on mobile.twitter.com

After a soft launch, we ran into some unexpected issues. Several common Firefox extensions insert Javascript on page load, thereby triggering a report. However, even more surprising were the number of ISPs who were inadvertently inserting Javascript or altering image tags to point to their caching servers. It was the first example of how CSP gave us visibility into what was happening on the user’s end. We addressed this problem by mandating SSL for Firefox 4 users, which prevents any alteration of our content.

http://c2.com/cgi/wiki?WikiDesignPrinciples

http://elabs.se/blog/15-you-re-cuking-it-wrong

http://dannorth.net/2011/01/31/whose-domain-is-it-anyway/

http://cuke4ninja.com/

http://www.infoq.com/articles/Accidental-Agilist = Johanna Rothman wrote:

I didn’t think if myself as an agilist, of course. I decided to experiment with some practices, such as pairing and TDD. I’d worked closely with a couple of people one-on-one, back when I was a developer, and I wasn’t sure if it was really pairing. So I tried pairing and TDD with a colleague, Keith Ray, at an AYE conference, and sure enough, it was just like what I had done at work. Except, Keith was much nicer than my work colleague back in the ‘80s.

:-)