ThoughtShapes - Development - Comments

You're a thinker...very

Rjae Easton — Thu, 31 Jul 2008 07:17:00 -0400

You're a thinker...very nice.

You are right: there is a not-so-subtle, yet abstract, concept here. But I personally think we should not discuss static members in terms of single, global instance. Using the word instance can mislead some because static members are shared amongst all instances of a type.

I discuss static members vs. non-static members in terms of type members and instance members. This eliminates any ambiguity in that there are members scoped to a type, accessible by referencing the type, and there are members scoped to a type instance, accessible by referencing that instance.

Regarding your

Anonymous — Wed, 30 Jul 2008 15:03:06 -0400

Regarding your point:

Static Methods are not Object-Oriented.
Static methods are very similar in nature to functions in a non-OO language like C. Yes, static methods are contained by a class and therefore different than C functions, but they are not associated with an object instance and are consequently very similar.

The way I look at it, in a slightly abstract sense, static methods are indeed associated with an object, but it is a single, global instance. This is the real problem of static methods; They imply a global variable.

Steve, “If they screw up a

teo — Thu, 19 Jun 2008 09:07:43 -0400

Steve,
“If they screw up a Math.Add kind of thing, you're likely to have many more problems on your plate than broken Add functionality”. You are right about this; I do have other major problems having developers implement the main logic of a module poorly or faulty and not mentioning missing requirements :(.
Before I started doing unit testing, I wrote the company framework and most of the methods are static; of course, it is a Framework! Well, now that we are doing unit testing we are paying the price of not been able to test several failure scenarios. Also, to test the business logic layer (where no data access is required; it should be mocked) we are forced to have a running database, because the auditing framework cannot be mocked. I guess we will fix this at some point.
Going back to your point, yes, there is a possibility that at some moment the Math.Add method must be mocked to throw an exception or condition a result. So if there is a remote possibility, why tie ourselves with static methods or sealed classes?
If been able to test code is our priority, we should not handcuff ourselves. I totally agree with you.
Regards,
Teo

Hi Teo, Glad to hear that

Steve Seymour — Wed, 18 Jun 2008 15:14:53 -0400

Hi Teo,

Glad to hear that you're testing. Isn't it great?

I'm halfway with you and halfway against you in regards to the Math.Add method. Logically speaking you're correct: why would anyone want to allow the possibility to break the laws of mathematics? On the other hand, though, it always depends on the situation...and in that statement lies the key to allowing such behavior overriding. Because I can likely answer "it depends" to just about any question you can fathom, this leads to a corollary: I want to allow my system to adapt to the situations I am not currently thinking of. I'll give you an example...

What if the code I am writing that depends upon Math.Add is supposed to handle an OutOfMemoryException that stems from the Math.Add method? Let's say for some reason this is a specific situation in which the user is to be presented with "We're sorry but the process is currently out of memory." A contrived example? Perhaps, but nevertheless it is possible and serves the purpose of providing me with an argument. How would I write a test for this situation if I can't override the Math.Add method? It would be almost impossible because I'd have to set up the environment to a point where a call to Math.Add causes such a condition...which would be impossible to do across different machines, would lead to a host of unpredictable results, etc.

Now, balance your thoughts with my inclination to create a flexible, free system. I wouldn't have such a problem because I'd be able to override that Add method and throw an OutOfMemoryException and therefore test to see how the client code of the Add method handles such a situation. If I had a nickel for each time I thought I was creating code that didn't have to be overriden only to later find out that it did, I wouldn't be a rich man but I'd have...say...over $1.50. :)

And, what is the risk to allowing such freedom in the system? Do we really think a developer is going to override an Add method and provide his/her own faulty addition? I doubt it very much. I've got a lot more to worry about on my plate on a typical project than worrying about such things as this.

An another note, am I writing a library for others to use? If so, do I ever think the clients of my Math.Add method are going to need to override it? If they are, do I care? They can write their own wrapper that uses my method and still get all their testing done, right? If so maybe I would do a static Add method. Again, it all depends. If I'm writing an application that uses the Add functionality I might want to make it virtual, wrap it with an interface, etc. If I'm writing a library maybe I would do the static method. There is never a completely clear cut answer because nothing in life is ever clear cut.

I'm not saying you're wrong by any means. I'm only sharing my thoughts. I like freedom. I don't like logical handcuffs. I like to do what I want to do when I want to do it. I like to throw rules out the window and instead think through the things I'm doing. I'm saying that using virtual leads to the kind of development life that I like. I think we're both on the same exact page and that I'm being nitpicky with you, but my nitpickiness is only to prove a point: Let people be free to do what they want. If they screw up a Math.Add kind of thing, you're likely to have many more problems on your plate than broken Add functionality.

Steve, After more than a

Teo — Wed, 18 Jun 2008 11:42:45 -0400

Steve,
After more than a year doing unit testing, I do agree 100% with “The tests drive the code”.
I also agree with your point about private methods. The unit tests are based on expectations and not the concrete implementation of the method been tested. A private method can be created to make the code more readable or for code reuse purposes.
Going back to static methods, since “The tests drive the code”, I would use static methods if I want to prevent a developer from mocking the behavior of a method. Let’s say Math.Add(int a, int b). Under no circumstance I’d want a developer mocking this method to say that 2+3 (a and b) should return 10.
Depending on the mocking framework, instead of using a static method, a non-virtual method would work. In my case, I am using RhinoMocks and by making a method non-virtual, I prevent it from been mocked.

I finally did upgrade to R#

Steve Seymour — Fri, 25 Jan 2008 15:05:46 -0500

I finally did upgrade to R# 3.0 and have been running the latest version for quite a while (the one they released before they start working on R# 4.x). I like a lot of things they did, mainly:

1.) Reformatting the layout of a class is really nice. You can even now have regions automatically wrapping specific sets of code. We don't usually like regions very much, but we do wrap our member variables with a region, so having this done automatically is a great feature.

2.) They have fixed the build issues related to running tests, especially when debugging tests. It used to be that if you hadn't changed any files and you chose to debug a test, a lot of build processing would first have to finish before you got to debug. This is not the case any longer.

3.) Overall it seems faster than previous versions

4.) I could probably list more but you get the drift: Aside from my next rant, they've done some great things to an already great product.

By far the biggest drawback to what they've done, as I've mentioned above but am now completely sure of, is completely destroy the unit test runner interface. It is horrible. I think it is the worst change I've ever experienced to a product that I regularly use....ever. Ever. I'm so disappointed with it. They've taken a perfectly fine interface and added all these bells and whistles that either don't work or that pollute your experience. Resharper 2.x's unit test runner was perfect in my mind. It did everything I want and it was so simple and easy to use. The new one is terrible, regardless of some of the "workarounds" above that really don't solve much.

I'm once again seriously thinking of going back to 2.x. It's too bad because the features they've added to 3.x are great other than the new unit runner. I use the unit runner so much that it greatly outweighs any of the other features.

It reminds me of when I was in junior high school, in art class. We were using scratch paper (the stuff with the black coating that you scratch to reveal a white or colored layer underneath). I did a scene with dinosaurs and it was really coming out great for a while. I couldn't leave it alone, though, and wanted to keep adding to it. Before I knew it my simple but nice scratch art turned into a mess. Yup, JetBrains has done the same with their unit runner.

Hmmm...I wonder if I can use the old unit runner with R# 3.x? I'll have to poke around a bit to find out.

Hi Robert! What you say

Jay — Fri, 02 Nov 2007 20:24:09 -0400

Hi Robert!

What you say makes a lot of sense, no surprise there, but I'm currently working on a project where the decision to use a particular database technology was made early on... pretty much at the beginning. Why? Well I don't want to use the wimpy excuse that "I wasn't working on the project at the time this decision was made", and even if I was I might not have been in position to directly work around this decision. Some of the decisions to select a database early were based on the following:

Our product is a website that we want to achieve scale on. And we wanted to be able to make performance measurements ASAP.
A database brings decades of doing certain things well. And we wanted to leverage that

Having said that, I also should tell you that: A) We are using Agile just as you describe and B) I >think< we used something akin to the repository concept in order to isolate the DB from other production code so that the other groups (we have multiple scrum teams running) wouldn't be blocked. I say Akin because we don't have a true in memory repository. We use NMock to "stub" out interfaces and inject test data.
With both of these statements, we are in a position (should we need to go in this direction) where we could change the DB, remove the DB etc, in a "safe": we have unit tests to catch dependencies but is anything truly 100% safe ;), and speedy (in a sprint) manner.

Having said all that, I do struggle (as I mentioned to Rjae) with the fact that we have what some people would consider business logic written into stored procedures, and I worry what the implications of changing the DB technologies would be underneath the interfaces we have.

So I have no problem with you saying "start with an in memory repository first." I truly feel that Agile and your 4th point "I’d make remaining neutral with respect to the piece of technology a design requirement and ensure that the development team knew to isolate that decision behind the appropriate interfaces" above are the ones that help us rule the day.

Great post! There is a TON of good material here. I'll come back to this post frequently.

The stuff we put up here is

Rjae Easton — Fri, 19 Oct 2007 12:46:36 -0400

The stuff we put up here is not so useful unless it is applied. It is a pleasure to hear that you find the thoughts compelling; your ideas around screening collaborators could yield what you are looking for - as long as you build something with them (however that materializes).

Feel free to tag this post; come back and let us know how your project progresses.

Thank you for this

Anonymous — Fri, 19 Oct 2007 08:13:06 -0400

Thank you for this interesting post. I have been wondering about how to "screen" potential collaborators for a complex open-source project I am working on and as a result of your well reasoned article now realise that the best approach is to let the end-users of my prototype create variants (or extend the code-base with new "types" to do the things that they are interested in; but I will probably never have time to address), and on the basis of the quality of their code and my subsequent communications with them I should be able to pick out those few developers that I want to have direct contact with as a pseudo-project leader.

Obviously, this will be all very informal and I am assuming that my initial prototype attracts sufficient users for the subset of them that are inclined to program will form a community of sorts.

As for problem#1. I read

Anonymous — Tue, 02 Oct 2007 04:16:18 -0400

As for problem#1. I read this blog and regretted updating from R#2 to R#3, but discovered now that there is a simple solution (phew).
- Alt+P toggles the output-pane for the "unit test sessions" tab.
- The "unit test sessions" tab also have a button (Show Output) that lets you choose wether to show the output-pane to the left, or bottom of, the unit-test explorer

Update: I installed the

Steve Seymour — Mon, 13 Aug 2007 09:19:00 -0400

Update:

I installed the latest R# 3.0 last Friday and I still don't think it's ready for primetime. It definitely behaved much, much better, but I experienced an annoying slowdown when opening up VB files. Whenever I typed in a VB file it would take somewhere in the realm of 10-15 seconds to see the characters show up on screen, and my CPU utilization was continuously very high. Just this morning I reverted back to 2.5.3.

I didn't always get this slow behavior, BTW, but often enough that my level of frustration was reached. Once it did start happening, it kept happening.

R# 3.0 is getting close, but in my eyes it's not quite there yet.

Hi Jay, Thanks for the

Steve Seymour — Sat, 30 Jun 2007 10:07:36 -0400

Hi Jay,

Thanks for the tips...I'll definitely try them out. Great to know that if I switch over again I can get the live templates back to normal and that I can see the stacktrace of a failed test by using the "Preview" button. I was in the midst of trying to get the live template feature to work as before and that's when VStudio crashed on me, so I said, "Back to 2.5 for me so I can get some work done."

I've been in a bit of correspondence with JetBrains over the preview button functionality, and the last I heard was that they are going to have "Preview" as the default. I also went back and forth with them a little about having the tab windows for success, failed, and ignored tests because I liked that feature--it was nice and easy for me to see everything at once, with the count for each category right on the tab. I'm not sure if they are going to give the tab feature back, but perhaps.

Makes me wonder about trying to take software to the next stage. I liked what they had before. Simple and easy to use. Sometimes features are well intended but don't really bring anything to the table besides confusion. I didn't get the chance to play with it long enough to really do a thoughtful analysis, but it did seem to me that all they managed to add was confusion to the UI. Maybe the concept of having multiple test sessions going will be good, maybe not.

And yup, you were right....we don't have anonymous comments enabled. You wouldn't believe the number of spam comments we get.

Good to see you around these parts, too.

~Steve

hmm. Not sure if you have

Jay — Fri, 29 Jun 2007 09:02:48 -0400

hmm. Not sure if you have moderator accepted comments but what I posted yesterday hasn't appeared so I'll try again.

Steve,
I am using .Net 3.0 and the preview pane does work as JetBrains mentioned, but the Unit Test session and the Unit Test Explorer windows do add more confusion to the running of unit tests. If I run an individual unit test, then do some stuff and run a different one... The old one I ran doesn't "clear" out nor does the session number change. It's all a bit discordant :P

As for the templates, I got them to work. Apparently you have to indicate what "context" the templates apply to. So if you goto Options-live templates click on one of your templates then edit it. All you need to do is click the hyperlink just under the template abbreviation text box and in the edit window that pops up designate the tempalte as a C# template and you are good to go!

On an unrelated note ... I got to play around with Team Systems's unit testing capabilities and they are VASTLY inferior to nunit and resharper :P

Hey steve. I too ran into

Jay — Thu, 28 Jun 2007 13:42:11 -0400

Hey steve.

I too ran into the same issue you reported with your templates. However there is a fix for this. Apparently in 3.0 they allow you to declare the context(s) under which a template can be run. (not sure if you could do this in 2.5).
What you need to do is go to the live templates. Click on the one you want and hit Edit. Then click the hyperlink just under the abbreviation text box (it will say something like: Available everywhere) and everywhere will be hyperlinked. A text box pops up and you can select the context under which the template runs. Once you've done this the formatting comes back.

I got the preview button working as before ... however the unit test session now seems more noisy to me and while's there is still good info there it's gotten harder to read.

On another note... I was playing around with MS's test stuff in Team System the other nite and Resharper absolutely blows it away. Resharper feels like a nice sports car and the Unit Testing stuff in team feels like a wheel :P

Jeff, I’m quite impressed

Steve Seymour — Wed, 11 Apr 2007 10:48:55 -0400

Jeff,

I’m quite impressed by your honesty and sincerity.

You are very much on the right track in terms of injecting dependencies into the system, regardless of whether it is done by Spring or your own framework (I prefer doing such a thing myself so I don’t have to rely upon a third party–unless there are other features of it that I find useful enough to use). This is one of the keys to creating a testable, flexible system. With this approach and with commitment on your part in terms of TDD, I’m confident you’ll soon see how much better a development world you can live in…and the more you’ll enjoy your work. Not a day goes by that I don’t greatly appreciate the tests in the system.

Thank you very much for your kind compliment, too.