The price of not trying

Eli Lopian    Reviews    

Twitter has been under a lot of fire when changing the replies policy, they still did the right thing.
They tried, if they wouldn’t try then they will be no way to progress and grow, if they become scared of user response, we will get a mediocre system.
Thanks for trying twitter and keep up the good work. 

Typemock in the local press

Eli Lopian    Reviews    

The local “The Marker” Magazine has published an article about startups in the current economical crisis.

There is a cool picture of some of the crew eating on the bar. We don’t normally eat there, but on a lower table that is out of the frame, but the bar makes the picture looks really cool. I am sitting in the center.

Due to the economic crisis, we have made some courageous decisions. But we are seeing more usage of Typemock Isolator. This is probably because we save enterprises time and money, by enabling their development teams to unit tests. This in turn lowers the cost of fixing bugs and the Time to Market.

Thanks Team.

Unit Tests and Developers under Pressure

Eli Lopian    .NET Tests, Agile, Reviews, TDD    

In TechEd 2008 David Platt interviewed Roy about the future of  TDD. You should really view the Tech-Talk as Dave is really funny, although he does miss the number of possible TLA’s (which he recursively defines as a TLA = Three Letter Acronym) by 300.

About 5 minutes into the session David asks a key question: “What happens if your boss comes and says: I’m in a hurry, I need this, come on we need to ship this, we need to hurry up, forget about the tests“. What do you do?

I think that David has a valid point that is extremely important to address, as many teams are under pressure and they willing to find any excuses to ‘just code’. This question is going to define where we are going as a profession.

So what keeps us professional, what keeps us from doing cowboy development as Dave suggested that has been proven to lead us to more costs?

As Roy Said, it is a well defined process that will save ourselves from this pitfall, and writing unit tests is one of them. Just like professional teams will not even think of ditching their QA process, developer teams can not afford, in these economic times, to ditch unit testing. As a matter of fact, once you start unit testing you will find that you will be under less pressure!

You will spend some time writing tests (which you would have spent anyway on manually testing the application), but the ease at which you can continue to add functionality without breaking the code, will return that investment in no time. So the quickest way to implement a feature is actually using unit tests! I have seen so many teams make the mistake of not writing the tests, and within a few hours, they are already introducing bugs and are afraid to add features as they might (and probably will) break the code.

So back to Dave’s question, what happens if your boss is in a hurry? Be professional, just write the code and the tests as fast as you can. This is the most efficient way to write software.

Typemock and Design Issues

Eli Lopian    Reviews, Uncategorized    

The new field mock feature that enables developers to mock fields has raised the questions:

• Who needs to mock fields, (only bad programmers)?
• Does Typemock advocate bad design?
• Is Typemock too powerful?

Advocating Good Design

Well, lets get one thing straight. I do advocate good design, the design of the software is an important factor and one that I spend a lot of time on. I don’t advocate bad design. But this has nothing to do with testing tools.

Separation of Concerns

Mixing the abilities of tools is not a very good idea, I can give you numerous examples: One is my friends combined DVD/VCR that didn’t last long, the DVD had missing functionality that made the machine obsolete. Having your testing tool and design tool in one can lead to the same results.
I believe in Separation of Concerns – the testing tool should help you test your software and give you the confidence that you code works, it should not (as much as possible) force you (or help you) to design your code. The design tools (refactoring) should enable you to design your code in a better way, it should not test your code. Testing and Designing are different mind-sets. When you are testing your code, you are thinking about the external API and the scenario that you are testing – trying to make the code fail. This is a different mind set then when designing your code, where you need to see the higher picture and how to put all the pieces together. That is why TDD has 3 different steps:  Test, Code, Refactor! (Where Refactor is the Design process)

So what about mocking fields

Enabling Field Mocking comes from the same philosophy: Let the developer test his code. There is such a beast called “public fields” in .NET and there are some teams that use them and need to test their code. To give them confidence in there code, we can create pragmatic tools that will enable these team to test their code base and thus help these teams become more agile. If we tell these teams that they cannot test there code unless they conform to one certain design, these teams will not become agile as the bar is too high.

And what about design

There are many tools that developers can use to design there code (before or after writing tests), from static code analyzers like fxCop to refactor tools like Visual Studio and Resharper, and of course code reviews (and pair programming) which I believe are the best tools for design.

Once you separate the testing phase from the design phase you will have the freedom to make the correct balance and thus the best design, Typemock actually helps you get BETTER designed software. As long as you start thinking about the design seriously (by ruthlessly refactoring) and stop relying on your testing tool to do your design for you.

Debugging Mocked Methods

Eli Lopian    Product, Reviews    

Although strict XP practices, value tests more then debugging, there are many cases where you still have to debug the code base to find defects. Doing this with mocked objects can be very fishy.

Evaluating Mocked Properties

When evaluating methods and Properties in the Debugger, the Debugger Hi-Jacks the running application to run the code that evaluate the values. A mocking framework doesn’t know that you are running in the debugger and will return the mocked value. This might cause the test to fail, because of unexpected calls or different return values.

Breaking While Recording

When in Natural Mocks recording block, breaking inside the block will lead to very strange results. This is because the Hi-Jacked threads that are evaluating Properties are being recorded and mocked. The current workaround is to turn off automatic property evaluation.

Debugging Mocked Methods

When stepping into a mocked method, or putting a break point on it, you will never reach the break point. This is because the method is mocked and is never actually run. This is very confusing and I have heard some developers spending a lot of time trying to understand what is happening.

Preview

These issues have been a major feature of our coming TypeMock version and will all be solved.

• Mocked Property and Method Evaluation will not change the test!
• Breaking in the Recording Block will nor mess up the recording!
• There is a visual cue that will allow you to see that the method is mocked.

Example of debugging a mocked method.

As you can see, it is very easy to see that the method is mocked and understand why you cannot step into the method.

What do you think of the visual cue?

We are thinking about adding more information to the editor

• Return Values
• Conditional Returns (based on arguments)
• Different instances

What other information would you like to know while debugging?

The Ultimate Proof for TypeMock

Eli Lopian    Product, Reviews    

When developer using TypeMock find it an indispensable tool, it is a sign that we really help ease the task of building lasting software.

Karell says it better:

The best way to see if you need something is to stop using it (or be prevented from using it) for a while and see if you reach out for it out of habit….

I quickly realized that TypeMock.NET had become such an important part of my testing process that I could no longer function without it. It is an indispensable tool and while I acquired another Mock tool I simply can’t do without TypeMock.NET.

Interview on DotNetRocks

Eli Lopian    Reviews    

Richard has invited me for a chat on DotNetRocks. The topic being Unit Testing and Dependency Injection. I still have to find a nice photo for the show. Stay tuned

MailFrame’s CodeSpell

Eli Lopian    Reviews    

I had quite an embarrassing moment when Scott Hanselman who is reviewing TypeMock.NET sent me his first impressions.
The e-mails where screen-shots of spelling typo’s in TypeMock’s API’s documentation. It turns out that there are quite a few spelling mistakes in the API’s documentation.

Well, we added a task to fix all these, but as we are software developers we looked for a tool that would do the job for us.

Not Much has changed since 2005, and ZMan’s blog has a good summary of the existing tools. We tried the $50 Keyoti StudioSpell and the $29 MailFrame’s CodeSpell. I am not going to do a complete review but CodeSpell found mistakes in comments and in method/variable naming in an integrated way (without popping up other dialogs) and apart from crashing the Visual Studio when parsing non Latin text, it runs in the background and marks mistakes in the editor as you type, this will keep our spelling correct as we develop (very agile). The StudioSpell did not find all the mistake and didn’t work in a very integrated way (you must initiate the speller rather then have the speller mark mistakes with a wave).

To check end user messages StudioSpell is probably better, but for comments and method names, CodeSpell is way better, and for $29 it is a no brainer. Thanks Will Ballard