ISerializable - Roy Osherove's Blog

When I first saw Josh Flanagan's Readable Fluent Regex Api, I loved it at first sight. Now I'm working on a demo for the upcoming DevTeach in Toronto, where I'll present how to build custom LINQ providers to various things.

I thought it would be interesting to see if using the fluent Regex API Josh created along with a LINQ query syntax would "work" for me, so I set out to create LINQ to Regex.

a couple of hours later, I like it pretty much :)

Here's what you can do with it:

you use the Regex.Query.Against(string), and you use the fluent API in the "where" part. but the results you get back are Regular Expression "Match" objects that give you the actual findings of instances that have passes the given criteria along with other data such as their index and such. it also works with grouping and other cool things done in the API.

the main work was to be able to parse the full expression tree that is created by the big "where" clause, and translate that into calls against, again, the fluent API classes Josh created. I also needed to add an "IsTrue()" method at the end of the where clause so that the lambda expression can be accepted by the compiler. it always returns true..

Downloads:

• Source along with tests and the readable regex library port I did
• Binaries in release for the project

You can also download both the source and the binaries from the assembla homepage of this project.

Future possible steps:

• make the underlying regex query a compiled query (run faster)
• some API tweaks perhaps?

How you can take part in this project:

I've put the sources on assembla: http://www.assembla.com/spaces/LinqToRegex/  and if you're interested in contributing to the project send me an email to Roy at osherove.com and I'll add you.

Here's a blog from someone I deeply respect. he just reopened it. let's hope this time Addy will share more of his thoughts with the world. I got to work with Addy when he was still living in Israel. Great guy, lots of knowledge, and you can be sure to expect some deep thoughts about scalability from someone who works as part of the Microsoft Live Services Infrastructure team.

Um, kids, Joel needs employees. So don't go to MS or Google, please?

Seriously, Joel? When was the last *important* thing you've built that didn't rely on some knowledge that came out of one of those two huge companies? The nice thing about being an architecture astronaut, is that every once in a while, you solve a real problem while trying to solve a different one. If MS and gogole didn't take on al these huge failing projects, how would the world learn about things like:

• Making huge teams scalable (or how *not* to)
• Creating very scalable architectures
• Identity
• WS Standards and Security
• Parallelism, synchronization
• Next generation languages and tools
• better tooling for existing languages
• Domain specific languages for solving complex and small problems
• lots more "little" solutions to many problems

People who work there don't work on hopeless projects, they go there to solve huge technological challenges that advance our software industry directly or indirectly by letting us know what the limits are in given contexts:

• A team of X size becomes a big problem if you manage it wrong (see "Vista Start menu Fiasco")
• Agile can work on larger teams (as long as you split them to smaller teams!) while people do other things as well
• Integrating winforms in the browser can lead to really bad things, but alternatives will be found
• How do you support X millions of transactions per minute?

Today was both a good day for e and a bad day for me. Good day because I managed to get a full suite of tests that were somehow failing to work again after a refactoring that got out of hand. Bad - because out of all the tests, one of them failed.

Here's the part I'm ashamed of:

I was working with a pair, and when we both looked at the failing test, I went out and said "Oh, I think this test is no longer valid. It may just need to be removed". We both knew it was still a valid test, that for some reason was failing. But I was on such a role with making everything work, that test was feeling like a thorn in my thumb that I wanted to get rid of.

It was a hard few minutes to convince ourselves to debug through the test and realize what the problem may be

So, denial pattern #1:

Forces: You just want to get on with your code, with only one or two tests that are "ruining the party"

Behavior:

Instead of fixing them debugging them or accepting that you might not have fixed everything, you try to tell yourself that the tests may no longer be valid without actually checking your assumption, which you really wish would be true.

How to avoid: work in pairs. It's harder to ignore a problem (or at least more awkward) with 4 eyes staring at it.

Hey, you decision makers up there at Microsoft. Maybe you didn't realize this, or maybe you're waiting for the community to let you know. Spec# is one awesome project that needs to become a real product.

It allows one to verify during compilation lots of things you'd usually write corner-case unit tests for, plus allows you to specify a standard behavioral contract for methods using attributes. Saves lots of time and lots of headaches.

Want To learn more?

• Go to the Spec# Homepage and to read about it and download a working version of it for VS 2005 or VS 2008
• Here's an interview Hanselman did on Spec#
• Here's a video from the Spec# session at Alt.NET Seattle

If the community is vocal enough about it, the research project just might become a real product. so if you like it, blog it.

No honey. I'm not going on this trip with you.

In regards to my post about injecting mocks and stubs using a container in your tests, Dave asks in the comments: Why would you want to do this in the first place?

Here are the things I can think about right now (pros and cons). I'd love to hear your thoughts.

Pros for using a container in your tests:

• Can lead to easier test maintainability. You can add new dependencies to object under test without worrying about existing tests that use that object, since those dependencies will usually be automatically stubbed out as part of the object creation process
• Allows easier focus on testing interaction. When you have a class that has 3+ dependencies, you'd usually want to have no more than one mock against which you'll test the interaction of the class, while the rest would be stubs.  Since everything is getting stubbed by default, all you need to worry about when writing the test is about the mock's expected interaction and perhaps setting one of the stubs to run using a specific behavior.  In any case, writing the boilerplate stubbing code for all the dependencies is spared from you, something which I have struggled with before

Cons of using a container:

• It could make the test a little less readable in terms of understanding what gets injected and what the actual dependencies are. Assuming the reader already knows how to use containers, there is still a very clear separation between setting up the container's mocks and stubs and looks at where they are being used. By design , a container's work is hidden under an abstraction layer, which also makes the test reader not see how the mocks and stubs fit together inside the object under test.

Not sure how I feel about this particular brand of testing syntax. still, it's good that someone thought this problem through - testing xml serialization attributes.

[via the morning brew]

I just learned something new: You can do parallel builds with MsBuild if you have a multi core CPU. awesome.

Someone asked for examples of how you'd inject stubs and mocks when you'd like your object under test to use a container such as StructureMap.

here are a couple of simple tests to show this using Typemock Isolator.

the first uses the string based mocks found in the free community version of Typemock Isolator. the second uses the natural style syntax in the enterprise edition:

• assume you have ILogger, IEmailer interfaces and a MessageManager class under test that takes both of these in the ctor.
• The logic under test is: if calling the emailer throws an exception, the logger should be called with the message that was sent

[Test, VerifyMocks]
public void MessageManager_FailsEmailing_LogsMessage_ReflectiveStructureMap()
{
    StructureMapConfiguration.BuildInstancesOf<IEmailer>().AddConcreteType<Emailer>();
    StructureMapConfiguration.BuildInstancesOf<ILogger>().AddConcreteType<Logger>();

    MockObject<IEmailer> emailStub = MockManager.MockObject<IEmailer>();
    emailStub.AlwaysThrow("Send", new Exception("fake exception"));

    MockObject<ILogger> logMock = MockManager.MockObject<ILogger>();
    logMock.ExpectCall("Write").Args("could not email message abc");

    ObjectFactory.InjectStub(emailStub.MockedInstance);
    ObjectFactory.Inject(logMock.MockedInstance);

    MessageManager mm = ObjectFactory.GetInstance<MessageManager>();
    mm.SendMessage("abc");
}

----------------------------------------

[Test, VerifyMocks]
public void MessageManager_FailsEmailing_LogsMessage_NaturalStructureMap()
{
    StructureMapConfiguration.BuildInstancesOf<IEmailer>().AddConcreteType<Emailer>();
    StructureMapConfiguration.BuildInstancesOf<ILogger>().AddConcreteType<Logger>();

    IEmailer emailStub = RecorderManager.CreateMockedObject<IEmailer>();
    ILogger logMock = RecorderManager.CreateMockedObject<ILogger>();

    using (RecordExpectations re = RecorderManager.StartRecording())
    {
        emailStub.Send("", "", "", "");
        re.Throw(new Exception("fake exception")).RepeatAlways();

        logMock.Write("could not email message abc");
    }

    ObjectFactory.InjectStub(emailStub);
    ObjectFactory.Inject(logMock);

    MessageManager mm = ObjectFactory.GetInstance<MessageManager>();
    mm.SendMessage("abc");
}