RosMockLyn – The API evolves: Part II
Last time I wrote about the creation of mocks and how I solved setting up method calls. Let’s delve into assertions.
RosMockLyn – The API evolves: Part I
This time around I want to talk about how my API started out.
RosMockLyn – Mocking an interface
What does one expect from a mocking framework? Well, d’oh… It mocks stuff! But what functionality? How should this functionality be accessed? How does it, once used in a test, read? That all is the topic of this post of my series. Enjoy!
RosMockLyn – An introduction
Now that I’ve been working on this project for quite some time, I was thinking it was about time to at least write about it. It’s going to be a story about how I had the idea and why I needed to go for it. Here goes!
How code can talk – Signatures and interfaces
I’ll start off with a small code sample. What could be read out of the signature of this method alone:
Quality is not negotiable…!
Sounds great, doesn’t it? Let me guess, you already worked on a project, that just had really nasty code, where you wondered if those that created it really knew what were doing. I guess we’ve all been there. On both, the receiving side, meaning having to maintain such a code base, but also on the other side, when we just started programming. I’ve recently heard this statement more and more. But you might already expect it, I’m not going to sell myself completely to the statement above. I will highlight two viewpoints, put them together in an imaginary scenario and then draw a conclusion.
Default to explicit interface implementation – yes or no?
I recently started at a new company. One of the first things that struck me as odd was the extensiveness of interfaces being implemented explicitly in one of the projects. I soon found out that one particular colleague made it his default to always implement interfaces explicitly.
Interested as to why he was defaulting to this he had a few arguments:
First post, yay!
Hi folks,