[TestMethod]
public void GetStringFromCharacters()
{
    var charList = Enumerable.Range(0, 10).Select(x => 'a').ToList();

    charList
        .Aggregate("", (inner, outer) => inner + outer.ToString() + ",")
        .Should()
        .Be("a,a,a,a,a,a,a,a,a,a");
}

The big thing here is the “” in the Aggregate method signature. That basically says that Inner is a string. If I didn’t have that specified, both inner and outer would be a character.


YAY

I was running the xUnit.gui.exe program to run units tests using xUnit… duh. Problem I ran into is that xUnit is not a part of the solution that the tests were. This caused issues when trying to run integration tests since the needed app.config wouldn’t be read by xUnit as the config file used when running an app is the config file from the topmost (Usually UI) project/application. So I made a wild guess that if I follow that logic, what little there may be, and add the connection strings to the xunit.gui.exe.config file as if it were an app.config/web.config, it should use the connection strings added… and turns out it did.

And there you have it… it being the solution and not a clown.

Basically take a number and divide it by another number 3 times.

let bytesToGb item =
let itemB = item / 1024I
let itemC = itemB / 1024I
let itemD = itemC / 1024I

Is the same as:
let bytesToGb item =
let x = x / 1024I
let x = x / 1024I
let x = x / 1024I

And more reduction:
let bytesToGb item =
item
|> (fun x -> x/1024L)
|> (fun x -> x/1024L)
|> (fun x -> x/1024L)

Or more:
let divide x = x/1024L
let bytesToGb = divide >> divide >> divide

If you’re familiar with Func/Action, Linq, ect this might actually look a lot like some of the newer “functional like” additions to C#. Well at least the third one. Funny part, and I didn’t know this, is that most of the more interesting additions to C# (Generics, Linq, Lambda expressions) actually came from F#; Which was built to match other existing functional languages like Haskel)  Go figure.

So one of the biggest pains in a place that doesn’t lend itself well to be in pain has been trying to unit test web forms like how MVC controllers can be. Before 4.0, this was an aggrevation at the least. Something in between stubbing one’s toe and getting only chocolate icecrfeam when you ask for a @*&*ing swirl. Serious, how hard is it to pull the swirl lever? Really.

Anyways, so there are certain things in .net web forms that were pretty difficult to hande/mock/get around for testing. Let’s take session for instance. Session is a sealed class with a non public constructor. To make things more interesting, the Page class only has a get for the Session property. Now you could go through a lot of hell, mostly reflection, to get aroud this, but who wants to do that? Personally I gave web forms the ole one finger salute, but being that I am working with web forms again… yeah had to find a way to get around this. The answer? Stems from dynamic.

Basically what I had to do is create a class that has a Session property that is dynamic, and then replace the old Session call with a class that calls a property named Session. The effect to the code, as far as the immediate code behind is concerned, is just this simple adding of the class before the Session call. Far as the code to do this, it’s fairly easy too.

First I started with an interface since using an interface will help later if I need to mock.

This is the bread and butter. Basically we have a container that will hold the session object. Making the property dynamic allows it to be set to anything. All I have to worry about is that whatever I set it to has the functionality used by Session. This is started by implementing the interface fo use on the site:

And then one for use with testing:

How are these used? Well if we take a base page:

So what this does is holds two constructors; One for use by .Net when it runs the site and one for the test class when it is testing the page functionality. The second is a way to stop all the stuff that happens in the Page class constructor when it’s time to unit test this [explitive]. This might look familiar to people who have used things such as Dependency Injection with MVC to help with Controller testing. If not, the idea is simple. It basically just gives the Page the test handler we need it to use when testing. If we aren’t testing, then we let it just use the default handler.

You might wonder why I didn’t instantiate the live version in the constructor, and the answer is: Session isn’t ready to be used at constructor time when doing the normal web site thing. Therefore, it will be set the first time the SessionHandler property is called. If it’s a test, well then it’s fine to set it in the constructor since it is bypassing the normal web site… thing.

The unit test looks something like this:

As you can see, a test version of the handler is created and the Session object is replaced with a Dictionary since that’s what Session is… well it has more to it but the most used feature is the key/value match and it happens to be the only part of Session I show in this example.

Since there is the second, test only, constructor on the page, we don’t have to worry about any asp.net stuff getting in the way when instantiating the page. The page will look like this:

As it can be see, the replacement of the Session call with SessionHandler.Session allows the features of Session but also the testability it lacked for so long. It’s true that if you want to use other features of Session, if there are any and I can’t remember, you’ll have to just add them to the test version so they can be called at test time. I can’t do everything for you.

Get a number in a list of integers that is closest to 0.

Sounds easy enough, right? Well there are a few more rules but nothing game breaking:

• If the list contains a 0 then return 0
• If the list is null then throw ArgumentNullException
• If list is empty then throw ArgumentException
• If there is no 0 then get the number nearest 0
• If the closest is the same for positive and negative (Say -2 and 2), return the positive

Again, fairly simple thing to work on.

Right off the bat I set about creating the method for doing this since my usual plan is:

1. Create method
2. Unit test
3. ???
4. #$@%!

The fourth step is actually repeated a couple times.

So after I had done the more brute force sort of way, and had a failing test, it was suggested I start over. This time stick with the TDD like mindset of

1. Create test
2. Fail test
3. Add code to make it work
4. Watch it succeed

Now the concept of TDD I have known about for a while, but never really had a chance to really jump into it. After all, most companies just want something done now, not done well. Beyond that, I had reservations of how it works and whether I was smart enough to pull it off. After all, I had always thought you have to be able to see the whole method before it’s written in order to create tests. Well after yesterday I can say I was wrong… at least about the second part.

When I started writing test methods I was told to make them each this way:

Always add to a method the most simple way to get a test to run.

Yeah ok, it sounded better when I heard it yesterday. However, I have examples.

So if we take the first requirement:

If listToCheck contains a 0 then return 0

Well what should I write as a test? Easy:

As you can see I am only checking to make sure there is a 0 returned. Side Note: You might notice that the method is red. This is because it hasn’t been created yet. That’s the next step. What should I put in the method? Remember I only want to put in the most simple way to get the test to pass.

Which gives me this guy:

Right now you’re probably thinking that test is the programing equivalent of Master of the Obvious. I mean, of course it passes because it always returns 0. The next unit test might help with seeing the bigger picture:

Ok so now I’m testing:

If the list is null then throw ArgumentNullException

So naturally I have a test that expects an ArgumentNullException to be thrown. I don’t have that yet in the method though so the expected result when running the test is:

Boom. Go figure. Next step is to add only what is necessary to make the unit test pass.

Now you can see that I have added an exception to be thrown if the list is null. Time to run the tests:

Now I know that the method does take care of the first two requirements. From here I go requirement by requirement and create unit tests to make sure the requirements are met and have them all fail at first. After the test fails, add in the minimal amount of code necessary to get the test to pass.

Eventually you will have a working method that is completely covered.

You might be wondering why this site still exists but you might also be wondering why you should go requirement after requirement adding just what’s needed. The answer is actually simple: It lets you know exactly what changes you make breaks any other test. You see, if you were to do the normal “build the method and test” and there’s a test failing, it becomes harder to track down the issue since the method is now a bunch of code. Since there are multiple points of failure when you start writing the tests, tracking down a specific error is hard.

If you go requirement by requirement, test by test, you can easily find anything that breaks the created tests since you are only working one requirement at a time. I the first three requirements are met and tested when you work on adding the fourth and for some reason what you added to the method is breaking one of the successful test, you know exactly where the issue is.

I have the code here if you want to look at it as I’ve I’ve commented a lot of the code. It is in VS 2010 though. However I don’t think there’s anything that couldn’t work in 3.5.

I admit it’s kind of a different way of looking at it, but I found it incredibly useful in it’s simplicity.

Dependency Injection
Entity Framework 4.0 with POCO
Inversion of Control with Castle
The IResult
jQuery
jQuery Ajax Posts
jQuery Custom Css
jQuery Validation
Mocking with Rhino Mocks
MVC 3/Razor
MVC Annotation Based Validation
What I call the Repository Pattern
Unit Tests - Integration With Entity Framework
Unit Test - MVC Controller Actions

And more s--t I can't think of right now!

What’s the price of this gem? Just your time which is worth nothing!

Where can you find it? Right here!

Requirements:

Visual Studios 4.0
Mvc 3
To open the solution and do a search and replace on "Tutorial" to set your directory paths.
A real f--king need to learn!

Act now, operators aren’t in existence since this is hosted on a website, but if they were they would be standing by!

Disclaimer:

This may or may not hit you with a wave of awesome. Be prepared for the worse case awesome scenario. I am in now way responsible for any heart stoppage due to the shock and awe power of the project.

Took a little bit to find this one, but changing the color of Errors and Warnings makes it hell of lot easier to find them. Go figure that the default “barely more grey than white” color doesn’t do the same.

Anyways:

File -> Settings -> IDE Settings -> Colors & Fonts -gt; General

At that point you’ll see stuff to the left with a bunch of colors. (Default Text) Just click on either Error or Warning to change them. After you’ve done that, feel free to go back to your project and find all the errors you couldn’t see before. It’s OK that you have errors though. Awesome as I am, even I make mistakes. Haha just kidding. Be ashamed of yourself.

someSession.query(SomeTableRepresentationObject).filter...ect

If you’ve used sqlalchemy, nothing new going on here but it wouldn’t be me if I didn’t point out the obvious and take three sentences to do so.

Now what you may run into is something like this:

def getCountOfUsersByUserName(userName, session):
  return session.query(User).filter(User.userName == userName).count()

Ok now that I typed that out, I see it’s kind of a dumb method. But f–k it, what’s done is done.

Now from a testing situation, this could look tough. After all if you come from a more static language background like I did, you should know how hard things can be to mock at times. (.Net Session… I’m looking at you with judging eyes. Sooooo judging.) But this isn’t a static language, it’s Python.

For purposes of making things less confusing, which is hard for me, when I use the word “Object” I mean method OR class. And remember as always, “banana” is the safe word.

You see, to mock that out all you need is an object that has a query object that takes in something and a filter object on the query object that takes in something and has a count method on it. Yeah that totally makes sense. Try working it backward.

Filter has one parameter and a count method on it. Whatever that parameter is, it doesn’t matter since it is Python. As long as Filter takes in one parameter, you have a winner.

Query, like Filter, takes in one parameter and has a object named Filter on it. Once again, it doesn’t matter what’s passed into Query, just that it takes something in.

Session is basically an object that has no parameters and has a Query object on it.

Now in a static language, this would be annoying. You would need 3 interfaces and mock a whole ton of stuff dynamically with something like Rhino Mocks or just create a bunch of classes of those interfaces that you can pass in. Either way, there are complications. Once you get into things like Web Session or ViewState, it’s a ton of work. Python? Eh, you can do it in 20ish lines. How you ask? Well I’ll show you how!

	class mockFilter(object): #This is the ONE parameter constructor
		def __init__(self):
			self._count = 0
			self._first = dynamicObject()

		def first(self):  #This is the another method that's just coming along for the ride.
			return self._first

		def count(self):  #This is the needed Count method
			return self._count

	class mockQuery(object): #This is the ONE parameter constructor
		def __init__(self):
			self._filter = mockFilter()

		def filter(self, placeHolder): #This is used to mimic the query.filter() call
			return self._filter 

	class mockSession(object):
		def __init__(self):
			self._query = mockQuery()
			self.dirty = []

		def flush(self):
			pass

		def query(self, placeHolder):  #This is used to mimic the session.query call
			return self._query

  #and this... THIS IS SPARTA!!1111... yeah I know, I'm about 3 years too late on that joke.

How does this work? Say I have the method from above:

def getCountOfUsersByUserName(userName, session):
  return session.query(User).filter(User.userName == userName).count()

I could test it using this:

  session = mockSession()
  session.query('').filter('')._count = 0 #Initialize the mock session so it returns 0 from count()

  getCountOfUsersByUserName('sadas', session)

And boom, you have mocking in ten minutes or less or your code is free.

As you can see, the highly dynamic nature of Python makes it a great fit for any project that will need unit tests and mocking. And which project doesn’t? You know what I’m sayin’? You now what I’m saying’? High five!

Note: dynamicObject is …. nothing but a cheesy class that inherits Object but has nothing on it. (Turns out that if I did someObject = Object() I couldn’t do this since Object by default doesn’t contain the ability to add things dynamically… and this was by design.)

And yes, I just quoted myself. I am that awesome.

For those bullet point programmers:

• The working demo can be found here
• The code can be easily downloaded

Now when I say validation, I mean the validation plugin. and this example is built using concepts in this post.

Here’s the markup:

<form id="formCheckBoxValidation" method="post" action="checkboxValidation.html">
	<input type="checkbox" id="checkBoxList" name="checkBoxList" value="One">
	<input type="checkbox" id="checkBoxList" name="checkBoxList" value="Two">
	<input type="checkbox" id="checkBoxList" name="checkBoxList" value="Three">
	<input type="checkbox" id="checkBoxList" name="checkBoxList" value="Four">
	<input type="checkbox" id="checkBoxList" name="checkBoxList" value="Five">
	<br />
	<input type="submit" id="buttonCheckBoxValidation">
</form>
<div>
	<div id="divError" name="divError" style="display:none;"></div>
</div>

<form id="formCheckBoxValidationDifferentName" method="post" action="checkboxValidation.html">
	<input type="checkbox" id="checkBoxListOne" name="checkBoxListOne" value="One">
	<input type="checkbox" id="checkBoxListTwo" name="checkBoxListTwo" value="Two">
	<input type="checkbox" id="checkBoxListThree" name="checkBoxListThree" value="Three">
	<br />
	<input type="submit" id="buttonCheckBoxValidationDifferentName">
</form>
<div>
	<div id="divErrorDifferentName" name="divErrorDifferentName" style="display:none;"></div>
</div>

For this example I’m actually presenting two examples(Say ‘example’ again, I dare you, I double dare you m—erf—er, say ‘example’ one more God d–n time!): If the checkboxes are linked by id and if the checkboxes are not linked at all. There is actually a difference. You see, if they share the same id, the required method can be used since it will treat them all as the same element and therefore if even on is checked, there is a value. Otherwise, you have to check all the checkboxes to see if at least one is checked. (Yeah, that made total sense.)

Here’s the check checkboxes method:

//Add a method to the validator that checks to see if at least one of the
//  three checkboxes specified are checked.
jQuery.validator.addMethod('atLeastOneChecked', function(value, element) {
	var checkedCount = 0;

	if (jQuery('#checkBoxListOne').is(':checked')){
		checkedCount += 1;
	}

	if (jQuery('#checkBoxListTwo').is(':checked')){
		checkedCount += 1;
	}

	if (jQuery('#checkBoxListThree').is(':checked')){
		checkedCount += 1;
	}

	return checkedCount > 0;
});

Oooooh baby.

Now for setting up the validation:

//This is for the first checkbox area where every checkbox has the same id causing them
//  to be a group and therefore the default required works.
var validationRules = new Object();
validationRules['checkBoxList'] = {required:true};

var validationMessages = new Object();
validationMessages['checkBoxList'] = {required:'at least one has be checked.'};

jQuery('#formCheckBoxValidation').validate({
	errorLabelContainer: '#divError',
	wrapper: 'div',
	rules: validationRules,
	messages: validationMessages,
	onfocusout: false,
	onkeyup: false,
	submitHandler: function (label) {
		alert('hooray');
	}
});

//This is for the second checkbox area where every checkbox has a different name
//  and therefore the atLeastOneChecked method must be used.
validationRules = new Object();
validationRules['checkBoxListOne'] = {atLeastOneChecked:true};

validationMessages = new Object();
validationMessages['checkBoxListOne'] = {atLeastOneChecked:'at least one has be checked.'};

jQuery('#formCheckBoxValidationDifferentName').validate({
	errorLabelContainer: '#divErrorDifferentName',
	wrapper: 'div',
	rules: validationRules,
	messages: validationMessages,
	onfocusout: false,
	onkeyup: false,
	submitHandler: function (label) {
		alert('hooray');
	}
});

In the words of Q-Bert: @#$% yeah!

You have a table for user to ignore users. So it’s basically a many to many where both sides of the relationship are the user table. The creation might look like this:

class User(Base):
    __tablename__ = "User"
    id = Column(String(36), primary_key=True, default=lambda : str(uuid1()))

Basically a table named User and it has a primary key. Yee haw. Now for the hanging table:

class UserIgnore(Base):
    __tablename__ = "UserIgnore"
    id = Column(String(36), primary_key=True, default=lambda : str(uuid1()))

    ignored_by_id = Column("ignored_by_id", String(36), ForeignKey("User.id"))
    ignored_by = relationship("User", backref="ignored_list",  primaryjoin=(User.id == ignored_by_id))
    ignored_id = Column("ignored_id", String(36), ForeignKey("User.id"))
    ignored = relationship("User", backref="ignored_by_list",  primaryjoin=(User.id == ignored_id))

Basically you need a table/object with two columns: ignored_by_id (The one doing the ignoring) and ignored_id (The one being ignored). And at this point the word “ignored” should look like it’s not even a word anymore because I’ve typed it too much already.

Now the relationship is made using two different properties:

    ...
    ignored_by = relationship("User", backref="ignored_list",  primaryjoin=(User.id == ignored_by_id))
    ...
    ignored = relationship("User", backref="ignored_by_list",  primaryjoin=(User.id == ignored_id))

As you can see, I had to hit it from both angles. (I’d hit it! LOLOLOLHARHARORAALROARH) Not only how to describe the relationship from ignorer to ignoree (Those are words now) but also in reverse. That way I can have a constructor like this:

    def __init__(self, user, userToIgnore):
        self.ignored_by = user
        self.ignored = userToIgnore

And also if I do something like this:

    UserIgnore(_user, _user2)
    UserIgnore(_user2, _user)

I can have it all save correctly just by adding _user to the session or saving _user id at some point.

Also both those lists will be added to the User object without having to do anything further.

someUser.ignored_list

or

someUser.ignored_by_list

Yay for that.

The label element does not render as anything special for the user. However, it provides a usability improvement for mouse users, because if the user clicks on the text within the label element, it toggles the control.

Quite simple put, if the user clicks the label or the input, it will put focus on the input. Yeah so not earth shattering but for people with stupid hands like me, it just gives me a better chance of actually clicking a textbox than the massive Evony Online ad right next to it.

  jQuery(ELEMENT_FORM).validate({
    errorLabelContainer: ELEMENT_ERROR_DIV,
    wrapper: 'div',
    rules: {
      textboxEmailAddress: {
        required: true,
        email: true
      }
    },
    messages: {
      textboxEmailAddress: {
        required: ERROR_EMAIL_ADDRESS_REQUIRED
      }
    },
    ....

As you can see, the elements like “textboxEmailAddress” are hard coded in there which means if that name changes in the markup, this breaks. So the question is: How do I script the rules and messages so that I don’t have to hard code the element names?

Sorry was just waiting for you to finish you question. Ok, here’s the answer and it has to do with how great Javascript is as a language. (And oddly enough a trick I got from Python)

  var validationRules = new Object();
  validationRules[ELEMENT_TEXTBOX_EMAIL] = {required:true};

  var validationMessages = new Object();
  validationMessages[ELEMENT_TEXTBOX_EMAIL] = {required:ERROR_EMAIL_REQUIRED};

  jQuery(ELEMENT_FORM).validate({
            errorLabelContainer: ELEMENT_ERROR_DIV,
            wrapper: 'div',
            rules: validationRules,
            messages: validationMessages,
            ....

Where ELEMENT_TEXTBOX_EMAIL is a constant somewhere. How does this work? Well because the way dynamic languages like Javascript and Python work, objects can be treated like dictionaries which means you can add properties to them the way you would add a record to a dictionary:

  someObject['somePropertyName'] = 'hi';

is just like:

  someObject.somePropertyName = 'hi';

In fact I’m pretty sure the new Dynamic keyword in C# works in the same manor.

Now you could be a annoying and point out that replacing textboxEmailAddress with ELEMENT_TEXTBOX_EMAIL is still hard coding, and I would agree… to a point. The constant does two things:

1) Removes a “magic string” from your code.

2) Makes it really easy to update that string if the element name/id is changed in the HTML. Having only to look at one place to replace is a lot easier than 1+ places.

So there, smarty pants. What you gots to say now?

So here’s a quick way to merge two objects in python:

def mergeObjectProperties(objectToMergeFrom, objectToMergeTo):
    """
    Used to copy properties from one object to another if there isn't a naming conflict;
    """
    for property in objectToMergeFrom.__dict__:
        #Check to make sure it can't be called... ie a method.
        #Also make sure the objectobjectToMergeTo doesn't have a property of the same name.
        if not callable(objectToMergeFrom.__dict__[property]) and not hasattr(objectToMergeTo, property):
            setattr(objectToMergeTo, property, getattr(objectToMergeFrom, property))

    return objectToMergeTo

This is a good example of how the whole dynamic addition of properties happens in Python. The objects in this example have a __dict__ property that is basically where the property/method/other stuff information is held in dictionary form. What does this mean? It means that if you use the setattr method you can then later call the property like you would normally.

  setattr(someObject, 'someProperty', 'some value')

  someObject.someProperty == 'some value

Knowing this is important as it allows you to really do some fun dynamic stuff that a lot of other languages just don’t allow.

If you’re using jQuery Validator and the built in validation methods just aren’t cutting, there’s a way you can add your own method to the validator itself. For this example let’s start some pretend time. Uhg I said pretend time not f–ked up fantasy time… Really, a horse? Really?

Now that we have that clear: Let’s pretend you have a form with three textboxes and you want to make sure one and only one is filled out. This doesn’t exactly fit the built in methods. Now you could try using the “required” method and replace it with a delegate. Could do that, but it ‘s  actually trickier than it sounds due to how required method actually works.  So what’s an easier way? Just add a method to the validator:

    jQuery.validator.addMethod('correctCountFilled', function(value, element) {
        var fullCount = 0;
        if(jQuery('#someTextBox1').val().length > 0){
            fullCount +=1;
        }

        if(jQuery('#someTextBox2').val().length > 0){
            fullCount +=1;
        }

        if(jQuery('#someTextBox3').val().length > 0){
            fullCount +=1;
        }

        return fullCount == 1;
    });

Then the call is done lika dis:

  ...

  rules: {
            someTextBox1: {
                correctCountFilled:  true  //This is the name of the method added and what it expects to come back when called to be valid.
            }
        },
  messages: {
            someTextBox1: {
                correctCountFilled: 'Some error message like pointing out how yours is a superior intellect.'
            }
        },
  ...

As you can see, the method returns false if all are empty or more than one is filled in. The method call on the validator expects “true” to be valid, so anything but one textbox being filled in will trigger the error message. Fairly easy, huh? Now go forth, be fruitful, and don’t multiply by mistake.

ANSWER:

In the development.ini file, place this under the [app:pytrends] area

mako.directories=projectName:folderWhereYourTemplatesAre

For example, the project I have is pyzazz (Don’t ask me what that is cause I don’t even know) and the template folder is… well templates. So I have it as:

mako.directories=pyzazz:templates

MORE USELESS WORDS:

When using pylons I used mako. It was fast and well it was by default. Now the default template engine is Chameleon which (Sorry Chameleon creator) sucks. First time using it, it was throwing parser errors in javascript lines like:

 if (urlParams.actual && urlParams.actual == 'true')

and it forced me to end an input with the </input> tag. And if you know anything about HTML, input tags DO NOT HAVE END TAGS. True story, go check w3.org if you feel like. Little things like that just annoy the hell out of me. Yeah I know it’s just html and javascript, the runts in the litter as far as programmers care, but you still can’t jack things up like that. And on that note: if someone who uses chameleon (Or helped write it) actually comes here, you are welcome to shoot down my claims.