Subscribe: Legend and truth
http://ondevelopment.blogspot.com/feeds/posts/default
Added By: Feedage Forager Feedage Grade B rated
Language:
Tags:
account  accountrepository  code  fake  fakeiteasy examples  fakeiteasy  found  login  new  part  password  public  string  test 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Legend and truth

Legend and truth



An opinionated .Net developers blog. The official blog for FakeItEasy.



Updated: 2018-03-07T22:25:11.470+01:00

 



Undefined… uhhh… defined

2011-12-06T10:59:07.867+01:00

Yes, we all know it, Javascript has some serious flaws. One of the more disturbing one being that undefined can be defined:

// This is way legal, but way weird:
undefined = “defined”;

Of course, it’s easy enough to avoid this, just don’t f-ing do it. But when writing scripts we are often playing in the same sandbox as the “big bad bullying, just straight up evil kids that has nothing better to do than going around defining undefined” are playing in. That’s why it’s very common to see scripts testing if the type of a value is “undefined” rather than to test if a value is equal to undefined:

// Test...
if (typeof foo === “undefined”) doStuff();
// ... rather than ...
if (foo === undefined) doStuff();

When I was a kid I alway wanted some sort of invisible shield to protected me from the big bad kids. Well, actually what I really, really wanted was some spinach to make me strong as Popey in order to beat the living crap out of the evil kids…

(image)

On the other hand, I guess a shield would do, I mean, even a visible shield would do. Can we please have a shield for our undefined??? Yes we can! And of course it comes in the form of a self invoking function as always when we want to shield our scripts.

(function(undefined) {
    if (something === undefined) doStuff();
}());

As you see here, we have an argument “undefined” in the function, however the function is self invoked without any argument thus the undefined argument has the value undefined. Inside this shield it’s perfectly safe to test for equality of undefined. This can be combined with other arguments as long as the undefined argument is the last one and the function is invoked with one argument less than the length of the arguments list:

(function($, global, undefined) {
    $(document).ready(function() {
        if (something === undefined) doStuff();
    });
}(jQuery, this));
(image)



An alternative to NotImplementedException

2011-04-10T10:51:32.817+02:00

It happens from time to time that I forget to implement some code where I’m just throwing a NotImplementedException. Being forgetful I have a habit of coming up with stuff that will help me not to forget. I think my “MustBeImplementedException” is quite useful, it will break the build if the build is not DEBUG.

#if DEBUG

namespace FakeItEasy
{
    using System;
    using System.Diagnostics.CodeAnalysis;

    /// 
    /// An exception that can be thrown before a member has been
    /// implemented, will cause the build to fail when not built in 
    /// debug mode.
    /// 
    [Serializable]
    [SuppressMessage("Microsoft.Design", "CA1032:ImplementStandardExceptionConstructors", Justification = "Never used in production.")]
    public class MustBeImplementedException
        : Exception
    {
    }
}

#endif
(image)



An old pain point removed from FakeItEasy

2011-04-02T13:37:08.410+02:00

It’s always bittersweet to say that you have introduced a breaking change in an API that people use. Bitter because it will break peoples code. But sweet because IT’S AN AWESOME NEW FEATURE!

I was never really fond of the fact that argument constraints relies on implicit casting in FakeItEasy, this is why you had to write A.Ignored.Argument but you could write the shorter A.Ignored for non interface types. This had to be done in order for the chaining of argument constraints to work: A.That.Contains(“foo”).And.Not.Contains(“bar”) for example. I thought I was pretty smart when I implemented this, it turns out though that ONCE in SEVERAL THOUSAND tests have I used this feature myself. Smart is never simple, smart is quite often stupid.

Now, I don’t wanna be stupid, so what can I do? I can remove the stupid feature. Said and done, in versions >= 1.7.* you can no longer chain argument constraints (but you weren’t doing that anyway).

Things that will break:

First of all, everything breaks at compile time so you won’t be able to build without fixing the problems. This is one of the benefits of a static type system, the complier will tell you what’s wrong!

.Argument

Any argument constraint will now return an instance of the constrained type (T) and not an ArgumentConstraint as it did in previous versions. This means that there is not property .Argument so you will have to remove any calls to that property from your tests. This might be quite many calls depending on how many tests you have and what you have been testing.

ArgumentConstraint

As I said this class is no more (RIP). The lowest level api for creating constraints is now the “Matches(Func predicate, Action descriptionWriter)” on the IArgumentConstraintManager type. You access an argument constraint manager through the A.That-property. This means that you can much more easily now provide extensions to the That-property, all you have to do is to create an extension method on IArgumentConstraintManager and call the Matches-method inside your extension method. Here’s an example on how the IsNull() argument constraint is implemeneted.

/// 
/// Constrains an argument so that it must be null (Nothing in VB).
/// 
/// The type of the argument.
/// The constraint manager to match the constraint.
/// A dummy argument value.
public static T IsNull(this IArgumentConstraintManager manager) where T : class
{
    return manager.Matches(x => x == null, x => x.Write("NULL"));
}

If you have extended the That-property before all your extensions will have to be rewritten to use the new API, it’s quite a simple task though and you’ll be glad that it will be much easier to create new extensions.

(image)



FakeItEasy breaking change for assertions

2011-02-14T21:32:49.079+01:00

In the latest version of FakeItEasy (version 1.6.4062.205) there is a breaking change in how repeats are specified in assertions. The reason for this is that the old way – while logically correct – was not intuitive to a lot of people.

Before you could write “Repeated.Once” and that assertion would pass even though the method you were asserting on had been called twice. Now, logically this makes perfect sense, a call that has happened twice has happened once. The problem is that I’ve noticed that people doesn’t think that way and therefore assertions has been wrong.

The reason I hasn’t changed this before is that if I did change it it would be a breaking change and it would just change under the feet of people that had figured the behavior out and I was reluctant to make a breaking change that doesn’t break the build.

The solution I came up with is one that does break the build. You can no longer write “Repeated.Once”, you have to write “Repeated.Exactly.Once” or “Repeated.AtLeast.Once” or “Repeated.NoMoreThan.Once” or any other repeat twice, Times(4) and so forth.

Hopefully you agree with my decision that it was important to break the build in this case and I hope that it doesn’t cause too much frustration, it is actually a quite straight forward matter of find and replace.

(image)



Experimental branches in Mercurial

2011-02-05T15:30:46.734+01:00

Branching in Mercurial is easy, it’s so easy that most of the times you’re branching you don’t even know that you’re doing it. Have you ever had to merge? I guess you have, well guess what, when you’re merging, you’re merging two branches! Ever got an error when pushing stating that a push would create two heads in the remote repository? Head == branch. I had a conversation the other day with a fellow developer about Git, I asked him what the main benefits of Git was. The thing is I’m pretty much Git illiterate. One of the things he said was the ease of branching and how local “throw away” branches can’t be done in Mercurial. First of all, I don’t know exactly how easy this is in Git so it might be harder in Mercurial but it’s definitely not hard. Let me show you! I’ll use TortoiseHG in this example since it’s visual and makes for better examples but it is just as easy to do it from the command line. Let’s start with a repository that contains a code file: Now, this class is boring, it only writes hello to the console and I’d like to spice it up a little, so I’ll do a spike. Let’s make it say “Hello Europe!”. Said and done, I edit the file and commit, now my repository looks like this: Now the thing is, while “Hello Europe!” is good I’d like to explore something differnt, let’s make it say “Hello World!” that’s so much more international. Let’s go back to before the change: Now, I change the code again, this time to “Hello World!” then I commit, now the repo looks like this: See, two branches, I could have backed to any point back in the revision history to branch from there. Now I’ve decided to go with the “Hello World!”-change and I want to push it to a central repo, I don’t want to include the “Hello Europe!” spike. Go into the repository explorer and click the “Determine and mark outgoing changesets”-button. This will mark change sets not already in the repository you’re pushing to with arrows: Right click the head of the branch you want to push and select “Push to here”. Now the repository you were pushing to will contain the following changesets: That’s pretty much all there is to it! One more thing though, what about deleting local branches that you don’t want to keep? This can be done with the strip command in the MqExtensions for Mercurial. Happy branching! [...]



Fixture initialization in FakeItEasy

2010-10-04T22:31:19.466+02:00

I added a new feature to FakeItEasy that makes it – you guessed it – easy to initialize test fixtures with fakes.

Instead of calling A.Fake() once for every fake you have in your test fixture you can simply tag the variables or properties you want to be fakes with the “FakeAttribute” and then call the method “Fake.InitializeFixture(this)” in your fixture setup:

[TestFixture]
public class InitializeFixtureIntegrationTests
{
    [Fake] IFormatProvider formatProvider;
    [Fake] IFormattable formattable;

    [SetUp]
    public void SetUp()
    {
        Fake.InitializeFixture(this);
    }

        
    [Test]
    public void Should...
(image)



Extending exception messages in FakeItEasy

2010-09-26T21:03:02.333+02:00

One of the main features of FakeItEasy is the informative exception messages, let’s say we have the following types:

public interface IPersonRepository
{
    void Save(Person personToSave);
}

public class Person
{
    public string FirstName { get; set; }

    public string LastName { get; set; }

    public DateTime DateOfBirth { get; set; }
}

Now, let’s create a test that shows us what the exception messages in fake it easy looks like when asserting:

public void Extending_exception_messages()
{
    var repository = A.Fake();

    repository.Save(new Person { FirstName = "Patrik", LastName = "Hägne", DateOfBirth = new DateTime(1977, 4, 5) });

    A.CallTo(() => repository.Save(A.Ignored)).MustNotHaveHappened();
}

This will yield an exception message that looks like this:

  Assertion failed for the following call:
    'FakeItEasy.Examples.IPersonRepository.Save()'
  Expected to find it exactly never but found it #1 times among the calls:
    1.  'FakeItEasy.Examples.IPersonRepository.Save(
            personToSave: FakeItEasy.Examples.Person)'

While this is a good exception message it doesn't say a whole lot about the person object that was used in the call to save. You could ofcourse in this particular instance override the ToString-method of person to fix this, but a lot of times you don’t have control over the types you use (for example the framework types). Now, fortunately, in the latest release of FakeItEasy, there is a dead simple way for you to provide your own formatter for printed argument values.

All you have to do is in your testproject define a class that inherits the FakeItEasy.ArgumentValueFormatter-class where T is the type of class you wish to provide custom formatting for.

Here’s an example of such a formatter for the Person-type:

public class PersonArgumentFormatter
    : ArgumentValueFormatter
{
    protected override string GetStringValue(Person argumentValue)
    {
        return string.Format("Person named {0} {1}, date of birth {2:yyyy-MM-dd} ({3} days old).",
            argumentValue.FirstName,
            argumentValue.LastName,
            argumentValue.DateOfBirth,
            DateTime.Now.Subtract(argumentValue.DateOfBirth).TotalDays);
    }
}

Now, let’s run the same test again and see what the exception message looks like: (I’ve split the message over several lines in this post so that the message will not be truncated by the blog).

  Assertion failed for the following call:
    'FakeItEasy.Examples.IPersonRepository.Save()'
  Expected to find it exactly never but found it #1 times among the calls:
    1.  'FakeItEasy.Examples.IPersonRepository.Save(
            personToSave: Person named Patrik Hägne,
                          date of birth 1977-04-05 (12227,874689919 days old).)'
(image)



FakeItEasy Login Service Example Series – Part 7

2010-07-24T11:18:51.969+02:00

This is the seventh and last part in the series of posts where I’m porting Brett Schucherts excelent demo of Mockito in Java to C# and FakeItEasy. The source for this example series can be found in a Mercurial repository at Google code. Each test implementation and following code update is a separate commit so you can easily update your repository to look at the full code at any given state. Find the repository here. Part 1 can be found here. Part 2 can be found here. Part 3 can be found here. Part 4 can be found here. Part 5 can be found here. Part 6 can be found here. Test 7 – Should not be able to log in to revoked account The next test is similar to the previous test. A revoked account does not allow logins: The test[Test] public void Should_throw_when_account_has_been_revoked() { // Arrange A.CallTo(() => this.account.IsRevoked).Returns(true); // Act, Assert Assert.Throws(() => this.service.Login("username", "password")); }   Test Description This test is a repeat of the previous test, checking for a different result from a different starting condition. Things Created for Compilation You'll need to add another exception, AccountRevokedException  and a new property, IsRevoked, to IAccount. Code Updated to get Test to turn Green The only update to get to green is adding a check - a guard clause - similar to the previous test:public void Login(string username, string password) { var account = this.accountRepository.Find(username); if (account == null) { throw new AccountNotFoundException(); } if (account.IsRevoked) { throw new AccountRevokedException(); } if (account.IsLoggedIn) { throw new AccountLoginLimitReachedException(); } if (account.PasswordMatches(password)) { account.SetLoggedIn(true); } else { if (this.previousUsername.Equals(username)) { this.numberOfFailedAttempts++; } else { this.numberOfFailedAttempts = 1; this.previousUsername = username; } } if (this.numberOfFailedAttempts == 3) { account.SetRevoked(true); } } Summary This has been a port of Brett’s original tutorial, his tutorial does not end here though no more tests are added. Please continue reading his tutorial. [...]



FakeItEasy Login Service Example Series – Part 6

2010-06-20T13:28:19.774+02:00

This is the sixth part in the series of posts where I’m porting Brett Schucherts excelent demo of Mockito in Java to C# and FakeItEasy. The source for this example series can be found in a Mercurial repository at Google code. Each test implementation and following code update is a separate commit so you can easily update your repository to look at the full code at any given state. Find the repository here. Part 1 can be found here. Part 2 can be found here. Part 3 can be found here. Part 4 can be found here. Part 5 can be found here. Test 6 – Exception thrown when account is not found This is a final test to make sure the code handles the case of an account not getting found. This is not too hard to write: The test[Test] public void Should_throw_when_account_does_not_exist() { // Arrange A.CallTo(() => this.accountRepository.Find(A.Ignored)).ReturnsNull(); // Act, Assert Assert.Throws(() => this.service.Login("username", "password")); } Test Description This test takes advantage of the fact that later configurations of a fake object takes precedence over earlier configurations, this differs from the way that Rhino Mocks works where earlier configurations has precedence. A login is attempted which should fail. Things Created for Compilation To get this test to compile, you'll need to add a new exception class:AccountNotFoundException.namespace FakeItEasy.Examples.LoginService { using System; public class AccountNotFoundException : Exception { } } Code Updated to get Test to turn Green The test currently fails with a null reference exception, a quick fix is needed at the top of the method.namespace FakeItEasy.Examples.LoginService { using System; public class LoginService { private IAccountRepository accountRepository; private int numberOfFailedAttempts; private string previousUsername; public LoginService(IAccountRepository accountRepository) { this.accountRepository = accountRepository; this.previousUsername = string.Empty; } public void Login(string username, string password) { var account = this.accountRepository.Find(username); if (account == null) { throw new AccountNotFoundException(); } if (account.IsLoggedIn) { throw new AccountLoginLimitReachedException(); } if (account.PasswordMatches(password)) { account.SetLoggedIn(true); } else { if (this.previousUsername.Equals(username)) { this.numberOfFailedAttempts++; } else { this.numberOfFailedAttempts = 1; this.previousUsername = username; } } if (this.numberOfFailedAttempts == 3) { account.SetRevoked(true); } } } } [...]



FakeItEasy Login Service Example Series – Part 5

2010-06-04T10:47:49.948+02:00

This is the fifth part in the series of posts where I’m porting Brett Schucherts excelent demo of Mockito in Java to C# and FakeItEasy. The source for this example series can be found in a Mercurial repository at Google code. Each test implementation and following code update is a separate commit so you can easily update your repository to look at the full code at any given state. Find the repository here. Part 1 can be found here. Part 2 can be found here. Part 3 can be found here. Part 4 can be found here. Test 5 – Do Not Allow a Second Login In the actual problem, counting concurrent logins was somewhat complex. For this example, we'll keep it simple. If you are already logged in, you cannot log in a second time. That's simple enough: The Test[Test] public void Should_not_allow_concurrent_logins() { // Arrange A.CallTo(() => this.account.PasswordMatches(A.Ignored)).Returns(true); A.CallTo(() => this.account.IsLoggedIn).Returns(true); // Act, Assert Assert.Throws(() => this.service.Login("username", "password")); } Test Description This test first sets the password to matching. However, it also sets a new property, IsLoggedIn, to always return true. It then attempts to login. The validation part of this test is in the Assert.Throws-part, which is a feature of NUnit. Things Created for CompilationFirst, create the new exception:namespace FakeItEasy.Examples.LoginService { using System; public class AccountLoginLimitReachedException : Exception { } } Next, add a new property to the IAccount interface, “IsLoggedIn”.When you make these changes, the test will fail and the message indicates it expected an exception. Code Updated to get Test to turn Green To get that exception thrown, simply make one small addition to the login method:namespace FakeItEasy.Examples.LoginService { using System; public class LoginService { private IAccountRepository accountRepository; private int numberOfFailedAttempts; private string previousUsername; public LoginService(IAccountRepository accountRepository) { this.accountRepository = accountRepository; this.previousUsername = string.Empty; } public void Login(string username, string password) { var account = this.accountRepository.Find(username); if (account.IsLoggedIn) { throw new AccountLoginLimitReachedException(); } if (account.PasswordMatches(password)) { account.SetLoggedIn(true); } else { if (this.previousUsername.Equals(username)) { this.numberOfFailedAttempts++; } else { this.numberOfFailedAttempts = 1; this.previousUsername = username; } } if (this.numberOfFailedAttempts == 3) { account.SetRevoked(true); } } } }  Note that this code would’ve been refactored a number of times if it was not example code. -Patrik [...]



FakeItEasy Login Service Example Series – Part 4

2010-05-25T20:52:13.790+02:00

This is the fourth part in the series of posts where I’m porting Brett Schucherts excelent demo of Mockito in Java to C# and FakeItEasy. The source for this example series can be found in a Mercurial repository at Google code. Each test implementation and following code update is a separate commit so you can easily update your repository to look at the full code at any given state. Find the repository here. Part 1 can be found here. Part 2 can be found here. Part 3 can be found here. Test 4 – Two Fails on One Account Followed By Fail on Second Account This is one of those requirements you ask "Really?!" This requirement comes from an actual project, so while it might sound bogus, it is an actual requirement from the real world. The Test[Test] public void Should_not_revoke_other_account_when_first_account_has_failed_to_log_in_twice() { // Arrange A.CallTo(() => this.account.PasswordMatches(A.Ignored)).Returns(false); var secondAccount = A.Fake(); A.CallTo(() => secondAccount.PasswordMatches(A.Ignored)).Returns(false); A.CallTo(() => this.accountRepository.Find("other username")).Returns(secondAccount); // Act this.service.Login("username", "wrong password"); this.service.Login("username", "wrong password"); this.service.Login("other username", "wrong password"); // Assert A.CallTo(() => secondAccount.SetRevoked(true)).MustNotHaveHappened(); } Test Description This test is a little longer because it requires more setup. Rather than possibly messing up existing tests and adding more setup to the fixture, I decided to do it in this test. There are alternatives to writing this test's setup: Leave it as is, it's not too bad. Add the additional setup to the SetUp() method, making this a larger fixture. Put this test is another fixture, different setup --> different fixture (this would be more of a BDD style). Since my primary purpose of this tutorial is to demo FakeItEasy, I'll leave it as is until I notice additional duplication. There are 4 parts to this test: Set the password matching to false on the account. Create a second account, with a never-matching password and register it with the account repository. Notice that this uses a particular account name, "other username". FakeItEasy, will use the latest configured call before any earlier configurations so this rule has precedence over the configuration in the setup that matches any account name. Login two times to the first account (both failing), then log in to a second account, also failing. That's three failures in a row, but to two different accounts, so no account should be revoked. Verify that the secondAccount is not revoked. Things Created for Compilation This test compiles without any new methods. It does fail with the following exception:Assertion failed for the following call: 'FakeItEasy.Examples.LoginService.IAccount.SetRevoked(True)' Expected to find it exactly never but found it #1 times among the calls: 1. 'FakeItEasy.Examples.LoginService.IAccount.PasswordMatches("wrong password")' 2. 'FakeItEasy.Examples.LoginService.IAccount.SetRevoked(True)' Code Updated to get Test to turn Green To get this new test to pass, I added a new member to the LoginService class: previousUsername. Then I updated the login method to take advantage of it:namespace FakeItEasy.Examples.LoginService { using System; public class LoginService { private IAccountRepository accountRepository; private int numberOfFailedAttempts; private string previousUsername; public LoginService(IAccountRepository accountRepository) { this.accountRepository = accountRepository; this.previousUsername = string.Empty; }[...]



FakeItEasy Login Service Example Series – Part 3

2010-05-25T20:52:36.944+02:00

This is the fourth part in the series of posts where I’m porting Brett Schucherts excelent demo of Mockito in Java to C# and FakeItEasy. The source for this example series can be found in a Mercurial repository at Google code. Each test implementation and following code update is a separate commit so you can easily update your repository to look at the full code at any given state. Find the repository here. Part 1 can be found here. Part 2 can be found here. Test 3 – Not logging in with wrong password The first two tests have made good progress, however to keep the number of assertions per test small (so far one) and to make individual tests less dependent on the underlying implementation, this next test forces a fix to the code and probably would have been a better second test than one you just created. The Test[Test] public void Should_not_log_in_when_password_is_wrong() { // Arrange A.CallTo(() => this.account.PasswordMatches(A.Ignored)).Returns(false); // Act this.service.Login("username", "wrong password"); // Assert A.CallTo(() => this.account.SetLoggedIn(true)).MustNotHaveHappened(); } Test Description This test takes advantage of the recent test refactoring. Before ever getting into the test method, the SetUp method: Created a fake IAccount. Created a fake IAccountRepository. Configured the IAccountRepository fake to return the fake IAccount for any username. Created a LoginService and injected the IAccountRepository. There’s not much left: Set the fake IAccount to not match any password. Attempt to login. Assert that the SetLoggedIn method is never called with true. Things Created for Compilation This test did not require any existing classes to have new methods added. Failing Test The test fails with this message, FakeItEasy finds the specified method call once and lists all the calls to the faked IAccount. Assertion failed for the following call: 'FakeItEasy.Examples.LoginService.IAccount.SetLoggedIn(True)' Expected to find it exactly never but found it #1 times among the calls: 1. 'FakeItEasy.Examples.LoginService.IAccount.SetLoggedIn(True)' 2. 'FakeItEasy.Examples.LoginService.IAccount.PasswordMatches("wrong password")'  Code Updated to get Test to turn Green The LoginService needs to be updated:namespace FakeItEasy.Examples.LoginService { using System; public class LoginService { private IAccountRepository accountRepository; private int numberOfFailedAttempts; public LoginService(IAccountRepository accountRepository) { this.accountRepository = accountRepository; } public void Login(string username, string password) { var account = this.accountRepository.Find(username); if (account.PasswordMatches(password)) { account.SetLoggedIn(true); } else { this.numberOfFailedAttempts++; } if (this.numberOfFailedAttempts == 3) { account.SetRevoked(true); } } } } [...]



FakeItEasy Login Service Example Series – Part 2

2010-05-25T20:52:47.758+02:00

This is the fourth part in the series of posts where I’m porting Brett Schucherts excelent demo of Mockito in Java to C# and FakeItEasy. The source for this example series can be found in a Mercurial repository at Google code. Each test implementation and following code update is a separate commit so you can easily update your repository to look at the full code at any given state. Find the repository here. Part 1 can be found here. Test 2 – Revoking accounts User story After three consecutive failed login attempts to the account, the account shall be revoked. The test[Test] public void Should_revoke_account_after_three_failed_login_attempts() { // Arrange var account = A.Fake(); A.CallTo(() => account.PasswordMatches(A.Ignored)).Returns(false); var accountRepository = A.Fake(); A.CallTo(() => accountRepository.Find(A.Ignored)).Returns(account); var service = new LoginService(accountRepository); // Act service.Login("username", "wrong password"); service.Login("username", "wrong password"); service.Login("username", "wrong password"); // Assert A.CallTo(() => account.SetRevoked(true)).MustHaveHappened(Repeated.Once.Exactly); } Test description Create a faked IAccount. Unlike the first test, this fake never matches any password. Create an IAccountRepository fake and register the IAccount fake with it for any username. Create the LoginService as before, injecting the IAccountRepository fake. Attempt to login three times, each time should fail. Finally, verify that the account was set to revoked after three times. Note that I specify the number of times it should be repeated to once exactly in this case, this is to show the syntax for how to specify repeat. In the first test we just said that the call should have happened any number of times, in this test we say that it must have happened exactly once. -Patrik Notice that this test does not check that SetLoggedIn is not called. It certainly could and that would make it in a sense more complete. On the other hand, it would also tie the test verification to the underlying implementation and also be testing something that might better be created as its own test (so that’s officially on the punch-list for later implementation). Things created for compilation Added the new method SetRevoked(bool isRevoked) to the IAccount-interface.namespace FakeItEasy.Examples.LoginService { public interface IAccount { bool PasswordMatches(string password); void SetLoggedIn(bool isLoggedIn); void SetRevoked(bool isRevoked); } } Failing test The test fails with the following message:Assertion failed for the following call:  'FakeItEasy.Examples.LoginService.IAccount.SetRevoked(True)'Expected to find it exactly once but found it #0 times among the calls:  1.  'FakeItEasy.Examples.LoginService.IAccount.SetLoggedIn(True)' repeated 3 times  Note that all the calls that has been made to the fake object are listed in the message so that you can easily see what is happening and why the test is failing. -Patrik Code updated to get test to turn green Here’s one way to make this test pass (and keep the first test green).namespace FakeItEasy.Examples.LoginService { using System; public class LoginService { private IAccountRepository accountRepository; private int numberOfFailedAttempts; public LoginService(IAccountRepository accountRepository) { this.accountRepository = accountRepository; } public void Login(string username, string password) { var account = this.accountRepository.Fi[...]



FakeItEasy Login Service Example Series – Part 1

2010-05-25T20:53:10.828+02:00

This is the first part in a series of blog posts that will demo FakeItEasy through TDD-ing a simple Login Service using C#. This is a port of Brett Schucherts excelent demo of Mockito in Java. As this is a demo of FakeItEasy, I will omit the refactoring part of Brett’s original example, please don’t miss it though as it can be found here. I’ve tried to stay as close to the original example as possible so that they can be easily compared. The source for this example series can be found in a Mercurial repository at Google code. Each test implementation and following code update is a separate commit so you can easily update your repository to look at the full code at any given state. Find the repository here. Getting started Create a new class library project in Visual Studio (or your IDE of choice). Create a new class library for the tests. Add a reference to the class library project from the test project. Download FakeItEasy and add a reference to FakeItEasy.dll from your test project. (Version 1.0.0.2 is used when writing this example.) Download NUnit and add a reference to nunit.framework.dll from your test project. (Version 2.5.0.9122 is used when writing this example.) Writing the tests What follows is a series of tests to get enough production code written to suggest a better implementation. The first purpose of this tutorial is to demonstrate using FakeItEasy for all types other than the underling LoginService. This is close to a classic mockist approach, though it varies in that I'm emphasizing testing interaction rather than state and deliberately trying to write stable tests that do not depend too much on the underling implementation. In support of this: All types used or needed by the underling LoginService will be represented as Interfaces (Interfaces will start with an I). All types used or needed by the underling LoginService will be created via FakeItEasy. I'm going to use Loose mocks - that is, you can call anything you want and the underling object will not complain. This is the default behavior of FakeItEasy. I'm going to minimally verify the expected resulting interactions (one assertion per test). I’ll only refactor the unit tests, for more on the refactoring of the production code see Brett’s original: refactoring to the state pattern. Test 1 – Basic Happy Path User Story When a user logs in successfully with a valid account id and password, the account’s state is set to logged in. The testnamespace FakeItEasy.LoginService.Tests { using FakeItEasy.Examples.LoginService; using NUnit.Framework; [TestFixture] public class LoginServiceTests { [Test] public void Should_set_account_to_logged_in_when_password_matches() { // Arrange var account = A.Fake(); A.CallTo(() => account.PasswordMatches(A.Ignored)).Returns(true); var accountRepository = A.Fake(); A.CallTo(() => accountRepository.Find(A.Ignored)).Returns(account); var service = new LoginService(accountRepository); // Act service.Login("username", "password"); // Assert A.CallTo(() => account.SetLoggedIn(true)).MustHaveHappened(); } } } Test description This test first creates a fake for an IAccount. There's no actual account class, just the interface. This fake is configured so that no matter what password is sent to it, it will always return true when asked if a provided password matches its password. Create a fake of an IAccountRepository. Associate the fake IAccount with the fake IAccountRepository. When asking for [...]



You don’t understand everything until you understand Nothing

2010-05-09T23:07:04.650+02:00

Here’s a piece of code that might or might not do what you expect. (It depends on what you expect it to do.)

Dim someAge = "999"
Dim parsedAge As Integer? = If(someAge = "999", Nothing, Integer.Parse(someAge)) 

Challenge

What will the parsedAge variable contain?

Answer

It will be a nullable integer with no value, right? Ehh, no wrong!

-So, what will it be?

Well, it will be a nullable integer – that’s the easy part – but it will have a value, zero (0)! Is this what you expected? It’s not what I expected when just gleening over the code. It’s not wrong or anything, it’s just that it’s not particularly intuitive.

It might be easier to see what happens here if we try to rewrite the same code in C#:

string someAge = “999”;
int? parsedAge = someAge == “999” ? null : int.Parse(someAge);

This will not even compile because the ternary operator must evaluate to a type and the compiler can’t figure out which type you want since an int value and null can never be of the same type.

So, why does it compile in VB? Well, because…

Nothing is not the same as null

- Huh? Nothing in VB is the same as null in C# right?

- Ehh, wrong!

Nothing is much more like the “default” keyword in C#. Nothing can be assigned to value type variables which will contain the default value of that type:

So let’s write C# code that is in fact equivalent to the VB code:

string someAge = “999”;
int? parsedAge = someAge == “999” ? default(int) : int.Parse(someAge);

Now, ofcourse “default(int)” will always return “0” so we could just as well write this:

int? parsedAge = someAge == “999” ? 0 : int.Parse(someAge);

Now it might be a bit more clear what happens; the ternary operator will always return an integer, either zero or the parsed string value, it will never return null and it will never return a nullable integer.

Now this is probably what threw me off to begin with: the result of the ternary operator is assigned nullable integer, leading us to believe that the result of the operator is a nullable integer when it infact never is. An int will be implicitly converted to a nullable int so the compiler will not complain here even though we technically have a type mismatch.

(image)



Return from sequence in FakeItEasy

2010-02-25T19:36:04.847+01:00

I added a nifty little feature in FakeItEasy today, not 100% sure about the naming though so if you have any ideas pleas tell me. The idea is that when you configure a call you can specify several values and each time a call is made to the configured member (property or method) the next value from the collection will be returned. Here’s what it looks like in action:

public interface ICurrentTimeProvider
{
    DateTime CurrentTime { get; }
}
 
[Test]
public void Example()
{
    var timeProvider = A.Fake();
 
    A.CallTo(() => timeProvider.CurrentTime).ReturnsNextFromSequence(
        DateTime.Parse("2000-01-01 01:00"),
        DateTime.Parse("2000-01-01 01:01"),
        DateTime.Parse("2000-01-01 01:02"));
 
    Console.WriteLine(timeProvider.CurrentTime); // Writes 2000-01-01 01:00
    Console.WriteLine(timeProvider.CurrentTime); // Writes 2000-01-01 01:01
    Console.WriteLine(timeProvider.CurrentTime); // Writes 2000-01-01 01:02
}
(image)



Not implemented? Implemented.

2010-01-06T11:13:27.145+01:00

I use the System.NotImplementedException a lot, whenever I create a new method I have it throwing this until I have let tests drive actual functionality of the method. There is a slight danger in this though (although better than the alternative) in that I might forget to implement a function and this exception creeps into production.

The other day I modified the snippet I use so that it outputs pre processor directives, so that the compiler will refuse to compile the code if I forget to implement such a method.

#if DEBUG
            throw new NotImplementedException();
#else
#error "Must be implemented to compile in configurations where the DEBUG constant is not defined."
#endif
(image)



Argument validation in FakeItEasy

2009-12-27T21:14:05.642+01:00

I created two more screencasts on FakeItEasy, these two are on the subject on argument validation, I’ve increased the font size and put some compressor on the audio to improve the quality a bit.

 

(image)



The basics of FakeItEasy

2009-12-26T17:48:45.653+01:00

I thought I’d take a stab at screencasts so here’s my first attempt, it’s a quick overview of the FakeItEasy framework:

(I would highly recommend that you watch it in HD-quality, otherwise the text will not be readable.)

(image)



Configuring any call to an object

2009-12-19T12:40:12.469+01:00

I’ve just updated the way to configure any call to faked objects in FakeItEasy, the syntax is new and also you can now configure return values.

Let’s say you have an interface providing localized text resources like this:

public interface ILocalizedResources
{
    string SomeText { get; }
    string SomeOtherText { get; }
}

When you fake this interface any of the properties would return null when not configured but you might have several tests that are dependant on that the values are non null strings but still you don’t want to have to configure each individual property in the set up of you fixture. Now you can do exactly that:

var resources = A.Fake();
Any.CallTo(resources).WithReturnType().Returns("");

Of course you can still configure any call to do anything you want just as before, for example:

var resources = A.Fake();
Any.CallTo(resources).Throws(new Exception());

 

Technorati-taggar: ,,,,,,
(image)



T4

2009-12-10T11:20:10.052+01:00

No, not that crappy movie but Text Template Transformation Toolkit.

I’ve played around with T4 every now and then over the last year but I’ve struggled to find any really good source for learning more. I guess the man who stands out from the crowd is Oleg Sych who has blogged about it en masse.

I’m watching a new screen cast by him on Channel 9 right now and it’s really good so please check it out.

(image)



New configuration syntax for FakeItEasy

2009-11-26T21:06:57.868+01:00

I’ve implemented a new, cleaner simpler, ninja-deluxe-shiny-gold-plated-ultra-cool way of configuring fakes/stubs/mocks in FakeItEasy.

The news are two fold:

  1. Simpler call specifications
  2. Simpler argument validations

How’s this for simple?

public void Example()
{
    var serviceProvider = A.Fake();
    var service = A.Fake();

    A.CallTo(() => serviceProvider.GetService(typeof(IWidgetFactory))).Returns(service);
}

No need for awkward lambda expressions where you have to split the configured method from the object that it’s called on.

Instead of:

serviceProvider.CallsTo(x => x.GetService(typeof(IWidgetFactory))

This reads better:

A.CallTo(() => serviceProvider.GetService(typeof(IWidgetFactory)))

As I mentioned argument validation has also become simpler, I mean, this is just childs play isn’t it?

A.CallTo(() => serviceProvider.GetService(A.Ignored)).Throws(new Exception());
A.CallTo(() => serviceProvider.GetService(A.That.Matches(_ => _.Name.StartsWith("A")))).Throws(new Exception());

The really cool thing is that you can define your own extension methods that provides validations for arguments, these extension will show up on the “That”-property, like this:

A.That.IsValidatedByMyVeryOwnExtensionMethod();
A.That.IsInSystemNamespace();
A.That.SpellsMyName();

It can be whatever you want, this means that you can effectively provide your own DSL for argument validation.

I’m thinking about providing an “An” class as well so that you can write the more grammatically correct “An.Ignored” rather than “A.Ignored”, but I’m not sure it’s worth it, maybe it’s confusing, what do you think?

I’ll be blogging about argument validations and how to provide your own extension super easy soon.

Technorati-taggar: ,,,,,
(image)



Fix that bug will ya? NO!

2009-11-07T12:02:39.649+01:00

If there’s a bug in software I’ve created my knee jerk reaction is that I created that bug. The knee jerk reaction of some developers is “there must be a bug in the framework”, which of course turns out to be false 99.9999% of the times. Yesterday I managed to track down a bug that had eluded me for a couple of weeks; an object graph that we’re serializing to the Asp.Net session (using state server) sometimes couldn’t be serialized. Every class that could possibly be contained in the graph was marked as serializable and also the error message wasn’t the one you get when you have a value that isn’t serializable in the graph. What I found was the following, we have classes similar to this:public interface IPredicate { bool Evaluate(object value); } [Serializable]public class AtLeastPredicate : IPredicate { private IComparable lowerBound; public AtLeastPredicate(IComparable lowerBound) { this.lowerBound = lowerBound; } public bool Evaluate(object value) { return this.lowerBound.CompareTo(value) <= 0; } } You’d think that you’d be able to serialize instances of the AtLeastPredicate-type right? As long as the “lowerBound” value it self is serializable you say. Yup, that should be it I say. Let’s try that:public class Program { public static void Main(string[] arguments) { var atLeastString = new AtLeastPredicate("bar"); atLeastString = SerializeAndDeserialize(atLeastString); Debug.Assert(atLeastString.Evaluate("foo")); } public static T SerializeAndDeserialize(T value) { var formatter = new BinaryFormatter(); using (var stream = new MemoryStream()) { formatter.Serialize(stream, value); stream.Seek(0, SeekOrigin.Begin); return (T)formatter.Deserialize(stream); } } } Yup, works like a charm as it should. So… What’s the problem? Well, let’s try that again:public class Program { public static void Main(string[] arguments) { var atLeastInt = new AtLeastPredicate(5); atLeastInt = SerializeAndDeserialize(atLeastInt); Debug.Assert(atLeastInt.Evaluate(10)); } public static T SerializeAndDeserialize(T value) { var formatter = new BinaryFormatter(); using (var stream = new MemoryStream()) { formatter.Serialize(stream, value); stream.Seek(0, SeekOrigin.Begin); return (T)formatter.Deserialize(stream); } } } Not much difference there, we’ve changed from comparing strings to comparing ints, and of course ints are serializable too so there should be no problem. But there is, this code will fail: Turns out that this is a bug in the .net framework:  http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=91177  Oh, well, I’ve created my share of bugs in my life so who am I to blame MS for doing that every once in a while. What I don’t get though is that this bug will not be fixed, I can’t really come up with a scenario where fixing this is a breaking change. Now, for sure, me not being able to come up with such a scenario doesn’t mean it doesn’t exist. I created an easy workaround for this however and since I was going to use it in a couple of places I encapsulated it in a class of its own:[Serializable] public class SerializableComparableField [...]



Configuring fake objects on a global scale

2009-11-01T12:39:02.859+01:00

In this post I’ll describe a way that lets you specify default configurations for specific types so that any time a fake of that type is created this default configuration will be applied. In FakeItEasy there’s a concept called a fake object container represented by the interface IFakeObjectContainer which has two methods, one for resolving/creating fakes and one for configuring fakes, in this post I’m going to focus on the configuration part.namespace FakeItEasy.Api { using System; using System.Collections.Generic; /// /// A container that can create fake objects. /// public interface IFakeObjectContainer { /// /// Creates a fake object of the specified type using the specified arguments if it's /// supported by the container, returns a value indicating if it's supported or not. /// /// The type of fake object to create. /// Arguments for the fake object. /// The fake object that was created if the method returns true. /// True if a fake object can be created. bool TryCreateFakeObject(Type typeOfFakeObject, IEnumerable arguments, out object fakeObject); /// /// Applies base configuration to a fake object. /// /// The type the fake object represents. /// The fake object to configure. void ConfigureFake(Type typeOfFakeObject, object fakeObject); } } Using the scoping feature you can actually plug in your own container for a given scope like this:using (Fake.CreateScope(new MyOwnContainer())) { } This means that within this scope your container will be used. Let’s focus on the ConfigureFake-method. This method will be called ANY time a fake object is created by FakeItEasy and lets us hook into the creation process and apply configuration to the generated fake object. This provides an easy way of defining default configuration for fakes of certain types which allows you to in your tests focus on configuring the values that are significant to the test. At the moment the default container is a class called NullFakeObjectContainer, which I’m sure you can guess does exactly nothing. However, there is an assembly distributed in the latest versions named FakeItEasy.Mef.dll. If you in your test-project adds a reference to this assembly FakeItEasy will automatically pick this up and use the MefContainer as the default container. And this is where the fun begins. The MEF assembly exposes two types that are significant to this feature, the most important one being IFakeConfigurator and the most used one being FakeConfigurator.namespace FakeItEasy.Mef { using System; using System.ComponentModel.Composition; /// /// Provides configurations for fake objects of a specific type. /// [InheritedExport(typeof(IFakeConfigurator))] public interface IFakeConfigurator { /// /// The type the instance provides configuration for. /// Type ForType { get; [...]



Asserting on exception messages in NUnit

2009-10-24T21:22:36.302+02:00

It seems to me that a lot of developers has missed the fact that Assert.Throws in NUnit actually returns the thrown exception which lets you assert on the message (and other properties of the exception). I wrote a response to a question on Stack Overflow which talks about this:

http://stackoverflow.com/questions/1609536/nunit-assert-throws

(image)