2011-01-21 20:54:55 -05:00
|
|
|
/**
|
|
|
|
* Tests method builder
|
|
|
|
*
|
|
|
|
* Copyright (C) 2010 Mike Gerwitz
|
|
|
|
*
|
|
|
|
* This file is part of ease.js.
|
|
|
|
*
|
|
|
|
* ease.js is free software: you can redistribute it and/or modify it under the
|
|
|
|
* terms of the GNU Lesser General Public License as published by the Free
|
|
|
|
* Software Foundation, either version 3 of the License, or (at your option)
|
|
|
|
* any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful, but WITHOUT
|
|
|
|
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License
|
|
|
|
* for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public License
|
|
|
|
* along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*
|
|
|
|
* @author Mike Gerwitz
|
|
|
|
*/
|
|
|
|
|
2011-11-05 08:52:19 -04:00
|
|
|
var shared = require( __dirname + '/inc-common' );
|
|
|
|
|
[#25] Finished refactoring MemberBuilder/MethodTest and removed inc-member_builder-common (no longer needed)
Finally feels like things are starting to come together.
It's rather interesting looking back. Each time I begin writing a piece of
software, I think to myself, "This is the best way to do it." Well, generally.
Perhaps the implementation could have been better, but I may not have had the
time. However, the general concept remains.
Each time I look back months later and find that I disagree with certain
decisions. I find certain implementations to be messy or poorly constructed. Or
perhaps I was just being lazy to begin with. Whatever the case, it is
comforting. It shows that one is continuing to learn and evolve.
Now, in the case of ease.js, we're working with a number of different factors in
regards to my perception of prior code quality. Primarily, I'm looking at a
basic implementation (in this case, I'm referring to test cases) that served as
a foundation that could be later evolved. I didn't have the time to devote to a
stronger solution. However, since the project has evolved so far past my
original expectations, a more sophisticated solution is needed in order to
simplify the overall design. That is what happened here.
Of course, we're also looking at a year's worth of additional, intimate
experience with a language.
Regardless of the reason, I love to see software evolve. Especially my own. It's
as if I'm watching my child grow. From that, I can get a great deal of
satisfaction.
One shouldn't expect perfection. But one should certainly aim for it.
2011-10-26 23:38:43 -04:00
|
|
|
require( 'common' ).testCase(
|
2011-08-31 00:24:19 -04:00
|
|
|
{
|
2011-11-03 23:20:45 -04:00
|
|
|
caseSetUp: function()
|
|
|
|
{
|
|
|
|
var _self = this;
|
|
|
|
|
|
|
|
this.testArgs = function( args, name, value, keywords )
|
|
|
|
{
|
2011-11-05 08:52:19 -04:00
|
|
|
shared.testArgs( _self, args, name, value, keywords, function(
|
|
|
|
prev_default, pval_given, pkey_given
|
|
|
|
)
|
2011-11-03 23:20:45 -04:00
|
|
|
{
|
2011-11-05 08:52:19 -04:00
|
|
|
var expected = _self.members[ 'public' ][ name ];
|
|
|
|
|
|
|
|
if ( !expected )
|
|
|
|
{
|
|
|
|
return prev_default;
|
|
|
|
}
|
|
|
|
|
|
|
|
return {
|
|
|
|
value: {
|
|
|
|
expected: expected,
|
|
|
|
given: pval_given.member,
|
|
|
|
},
|
|
|
|
keywords: {
|
|
|
|
expected: expected.___$$keywords$$, // XXX
|
|
|
|
given: pkey_given,
|
|
|
|
},
|
|
|
|
};
|
|
|
|
} );
|
2011-11-03 23:20:45 -04:00
|
|
|
};
|
|
|
|
},
|
|
|
|
|
|
|
|
|
[#25] Finished refactoring MemberBuilder/MethodTest and removed inc-member_builder-common (no longer needed)
Finally feels like things are starting to come together.
It's rather interesting looking back. Each time I begin writing a piece of
software, I think to myself, "This is the best way to do it." Well, generally.
Perhaps the implementation could have been better, but I may not have had the
time. However, the general concept remains.
Each time I look back months later and find that I disagree with certain
decisions. I find certain implementations to be messy or poorly constructed. Or
perhaps I was just being lazy to begin with. Whatever the case, it is
comforting. It shows that one is continuing to learn and evolve.
Now, in the case of ease.js, we're working with a number of different factors in
regards to my perception of prior code quality. Primarily, I'm looking at a
basic implementation (in this case, I'm referring to test cases) that served as
a foundation that could be later evolved. I didn't have the time to devote to a
stronger solution. However, since the project has evolved so far past my
original expectations, a more sophisticated solution is needed in order to
simplify the overall design. That is what happened here.
Of course, we're also looking at a year's worth of additional, intimate
experience with a language.
Regardless of the reason, I love to see software evolve. Especially my own. It's
as if I'm watching my child grow. From that, I can get a great deal of
satisfaction.
One shouldn't expect perfection. But one should certainly aim for it.
2011-10-26 23:38:43 -04:00
|
|
|
setUp: function()
|
|
|
|
{
|
|
|
|
// stub factories used for testing
|
|
|
|
var stubFactory = this.require( 'MethodWrapperFactory' )(
|
|
|
|
function( func ) { return func; }
|
|
|
|
);
|
2011-01-21 20:54:55 -05:00
|
|
|
|
[#25] Finished refactoring MemberBuilder/MethodTest and removed inc-member_builder-common (no longer needed)
Finally feels like things are starting to come together.
It's rather interesting looking back. Each time I begin writing a piece of
software, I think to myself, "This is the best way to do it." Well, generally.
Perhaps the implementation could have been better, but I may not have had the
time. However, the general concept remains.
Each time I look back months later and find that I disagree with certain
decisions. I find certain implementations to be messy or poorly constructed. Or
perhaps I was just being lazy to begin with. Whatever the case, it is
comforting. It shows that one is continuing to learn and evolve.
Now, in the case of ease.js, we're working with a number of different factors in
regards to my perception of prior code quality. Primarily, I'm looking at a
basic implementation (in this case, I'm referring to test cases) that served as
a foundation that could be later evolved. I didn't have the time to devote to a
stronger solution. However, since the project has evolved so far past my
original expectations, a more sophisticated solution is needed in order to
simplify the overall design. That is what happened here.
Of course, we're also looking at a year's worth of additional, intimate
experience with a language.
Regardless of the reason, I love to see software evolve. Especially my own. It's
as if I'm watching my child grow. From that, I can get a great deal of
satisfaction.
One shouldn't expect perfection. But one should certainly aim for it.
2011-10-26 23:38:43 -04:00
|
|
|
this.sut = this.require( 'MemberBuilder' )(
|
2011-11-02 19:12:15 -04:00
|
|
|
stubFactory, stubFactory,
|
|
|
|
this.mockValidate = this.getMock( 'MemberBuilderValidator' )
|
[#25] Finished refactoring MemberBuilder/MethodTest and removed inc-member_builder-common (no longer needed)
Finally feels like things are starting to come together.
It's rather interesting looking back. Each time I begin writing a piece of
software, I think to myself, "This is the best way to do it." Well, generally.
Perhaps the implementation could have been better, but I may not have had the
time. However, the general concept remains.
Each time I look back months later and find that I disagree with certain
decisions. I find certain implementations to be messy or poorly constructed. Or
perhaps I was just being lazy to begin with. Whatever the case, it is
comforting. It shows that one is continuing to learn and evolve.
Now, in the case of ease.js, we're working with a number of different factors in
regards to my perception of prior code quality. Primarily, I'm looking at a
basic implementation (in this case, I'm referring to test cases) that served as
a foundation that could be later evolved. I didn't have the time to devote to a
stronger solution. However, since the project has evolved so far past my
original expectations, a more sophisticated solution is needed in order to
simplify the overall design. That is what happened here.
Of course, we're also looking at a year's worth of additional, intimate
experience with a language.
Regardless of the reason, I love to see software evolve. Especially my own. It's
as if I'm watching my child grow. From that, I can get a great deal of
satisfaction.
One shouldn't expect perfection. But one should certainly aim for it.
2011-10-26 23:38:43 -04:00
|
|
|
);
|
2011-01-21 21:53:31 -05:00
|
|
|
|
[#25] Finished refactoring MemberBuilder/MethodTest and removed inc-member_builder-common (no longer needed)
Finally feels like things are starting to come together.
It's rather interesting looking back. Each time I begin writing a piece of
software, I think to myself, "This is the best way to do it." Well, generally.
Perhaps the implementation could have been better, but I may not have had the
time. However, the general concept remains.
Each time I look back months later and find that I disagree with certain
decisions. I find certain implementations to be messy or poorly constructed. Or
perhaps I was just being lazy to begin with. Whatever the case, it is
comforting. It shows that one is continuing to learn and evolve.
Now, in the case of ease.js, we're working with a number of different factors in
regards to my perception of prior code quality. Primarily, I'm looking at a
basic implementation (in this case, I'm referring to test cases) that served as
a foundation that could be later evolved. I didn't have the time to devote to a
stronger solution. However, since the project has evolved so far past my
original expectations, a more sophisticated solution is needed in order to
simplify the overall design. That is what happened here.
Of course, we're also looking at a year's worth of additional, intimate
experience with a language.
Regardless of the reason, I love to see software evolve. Especially my own. It's
as if I'm watching my child grow. From that, I can get a great deal of
satisfaction.
One shouldn't expect perfection. But one should certainly aim for it.
2011-10-26 23:38:43 -04:00
|
|
|
this.members = this.sut.initMembers();
|
|
|
|
},
|
2011-11-03 23:20:45 -04:00
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* The validator can only do its job if we're providing it with the correct
|
|
|
|
* information
|
|
|
|
*/
|
|
|
|
'Passes proper data to validator when not overriding': function()
|
|
|
|
{
|
|
|
|
var _self = this,
|
|
|
|
called = false,
|
|
|
|
|
|
|
|
name = 'foo',
|
|
|
|
value = function() {},
|
|
|
|
keywords = {}
|
|
|
|
;
|
|
|
|
|
|
|
|
this.mockValidate.validateMethod = function()
|
|
|
|
{
|
|
|
|
called = true;
|
|
|
|
_self.testArgs( arguments, name, value, keywords );
|
|
|
|
};
|
|
|
|
|
|
|
|
this.sut.buildMethod(
|
|
|
|
this.members, {}, name, value, keywords, function() {}, 1, {}
|
|
|
|
);
|
|
|
|
|
|
|
|
this.assertEqual( true, called, 'validateMethod() was not called' );
|
|
|
|
},
|
|
|
|
|
|
|
|
|
|
|
|
'Passes proper data to validator when overriding': function()
|
|
|
|
{
|
|
|
|
var _self = this,
|
|
|
|
called = false,
|
|
|
|
|
|
|
|
name = 'foo',
|
|
|
|
value = function() {},
|
|
|
|
keywords = { 'override': true }
|
|
|
|
;
|
|
|
|
|
|
|
|
// since we're overriding
|
|
|
|
( this.members[ 'public' ].foo = function() {} ).___$$keywords$$ =
|
|
|
|
{ 'public': true };
|
|
|
|
|
|
|
|
this.mockValidate.validateMethod = function()
|
|
|
|
{
|
|
|
|
called = true;
|
|
|
|
_self.testArgs( arguments, name, value, keywords );
|
|
|
|
};
|
|
|
|
|
|
|
|
this.sut.buildMethod(
|
|
|
|
this.members, {}, name, value, keywords, function() {}, 1, {}
|
|
|
|
);
|
|
|
|
|
|
|
|
this.assertEqual( true, called, 'validateMethod() was not called' );
|
|
|
|
},
|
[#25] Finished refactoring MemberBuilder/MethodTest and removed inc-member_builder-common (no longer needed)
Finally feels like things are starting to come together.
It's rather interesting looking back. Each time I begin writing a piece of
software, I think to myself, "This is the best way to do it." Well, generally.
Perhaps the implementation could have been better, but I may not have had the
time. However, the general concept remains.
Each time I look back months later and find that I disagree with certain
decisions. I find certain implementations to be messy or poorly constructed. Or
perhaps I was just being lazy to begin with. Whatever the case, it is
comforting. It shows that one is continuing to learn and evolve.
Now, in the case of ease.js, we're working with a number of different factors in
regards to my perception of prior code quality. Primarily, I'm looking at a
basic implementation (in this case, I'm referring to test cases) that served as
a foundation that could be later evolved. I didn't have the time to devote to a
stronger solution. However, since the project has evolved so far past my
original expectations, a more sophisticated solution is needed in order to
simplify the overall design. That is what happened here.
Of course, we're also looking at a year's worth of additional, intimate
experience with a language.
Regardless of the reason, I love to see software evolve. Especially my own. It's
as if I'm watching my child grow. From that, I can get a great deal of
satisfaction.
One shouldn't expect perfection. But one should certainly aim for it.
2011-10-26 23:38:43 -04:00
|
|
|
} );
|