2011-11-03 21:23:40 -04:00
|
|
|
/**
|
|
|
|
* Simple X-Unit-style test cases
|
|
|
|
*
|
2013-12-20 01:11:26 -05:00
|
|
|
* Copyright (C) 2011, 2012, 2013 Mike Gerwitz
|
2011-11-03 21:23:40 -04:00
|
|
|
*
|
2013-12-22 09:37:21 -05:00
|
|
|
* This file is part of GNU ease.js.
|
2011-11-03 21:23:40 -04:00
|
|
|
*
|
|
|
|
* ease.js is free software: you can redistribute it and/or modify it under the
|
Relicensed under the GPLv3+
This project was originally LGPLv+-licensed to encourage its use in a community
that is largely copyleft-phobic. After further reflection, that was a mistake,
as adoption is not the important factor here---software freedom is.
When submitting ease.js to the GNU project, it was asked if I would be willing
to relicense it under the GPLv3+; I agreed happily, because there is no reason
why we should provide proprietary software any sort of edge. Indeed, proprietary
JavaScript is a huge problem since it is automatically downloaded on the user's
PC generally without them even knowing, and is a current focus for the FSF. As
such, to remain firm in our stance against proprietary JavaScript, relicensing
made the most sense for GNU.
This is likely to upset current users of ease.js. I am not sure of their
number---I have only seen download counts periodically on npmjs.org---but I know
there are at least a small number. These users are free to continue using the
previous LGPL'd releases, but with the understanding that there will be no
further maintenance (not even bug fixes). If possible, users should use the
GPL-licensed versions and release their software as free software.
Here comes GNU ease.js.
2013-12-20 01:00:35 -05:00
|
|
|
* terms of the GNU General Public License as published by the Free Software
|
|
|
|
* Foundation, either version 3 of the License, or (at your option) any later
|
|
|
|
* version.
|
2011-11-03 21:23:40 -04:00
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful, but WITHOUT
|
|
|
|
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
|
Relicensed under the GPLv3+
This project was originally LGPLv+-licensed to encourage its use in a community
that is largely copyleft-phobic. After further reflection, that was a mistake,
as adoption is not the important factor here---software freedom is.
When submitting ease.js to the GNU project, it was asked if I would be willing
to relicense it under the GPLv3+; I agreed happily, because there is no reason
why we should provide proprietary software any sort of edge. Indeed, proprietary
JavaScript is a huge problem since it is automatically downloaded on the user's
PC generally without them even knowing, and is a current focus for the FSF. As
such, to remain firm in our stance against proprietary JavaScript, relicensing
made the most sense for GNU.
This is likely to upset current users of ease.js. I am not sure of their
number---I have only seen download counts periodically on npmjs.org---but I know
there are at least a small number. These users are free to continue using the
previous LGPL'd releases, but with the understanding that there will be no
further maintenance (not even bug fixes). If possible, users should use the
GPL-licensed versions and release their software as free software.
Here comes GNU ease.js.
2013-12-20 01:00:35 -05:00
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
|
|
|
|
* more details.
|
2011-11-03 21:23:40 -04:00
|
|
|
*
|
Relicensed under the GPLv3+
This project was originally LGPLv+-licensed to encourage its use in a community
that is largely copyleft-phobic. After further reflection, that was a mistake,
as adoption is not the important factor here---software freedom is.
When submitting ease.js to the GNU project, it was asked if I would be willing
to relicense it under the GPLv3+; I agreed happily, because there is no reason
why we should provide proprietary software any sort of edge. Indeed, proprietary
JavaScript is a huge problem since it is automatically downloaded on the user's
PC generally without them even knowing, and is a current focus for the FSF. As
such, to remain firm in our stance against proprietary JavaScript, relicensing
made the most sense for GNU.
This is likely to upset current users of ease.js. I am not sure of their
number---I have only seen download counts periodically on npmjs.org---but I know
there are at least a small number. These users are free to continue using the
previous LGPL'd releases, but with the understanding that there will be no
further maintenance (not even bug fixes). If possible, users should use the
GPL-licensed versions and release their software as free software.
Here comes GNU ease.js.
2013-12-20 01:00:35 -05:00
|
|
|
* You should have received a copy of the GNU General Public License along with
|
|
|
|
* this program. If not, see <http://www.gnu.org/licenses/>.
|
2011-11-03 21:23:40 -04:00
|
|
|
*
|
|
|
|
* @author Mike Gerwitz
|
|
|
|
*/
|
Added very basic formatted output and failure tolerance for test case
The one year anniversary of the beginning of the ease.js project is quickly
approaching. I find myself to be not quite where I had expected many months ago,
but find that the project has evolved so much further than I had event
originally anticipated. My main motivation behind the project continues to be
making my life at work easier, while providing an excellent library that others
can hopefully benefit from. If anything, it's a fascinating experiment and
clever hack around JavaScript.
Now I find myself with a newborn child (nearly four weeks old), who demands my
constant attention (and indeed, it is difficult to find the desire to put my
attention elsewhere). Still - I am a hacker. Software is my passion. So the
project must move forward.
I also find myself unwilling to create a blog for ease.js. I feel it's
inappropriate for a project that's in its (relative) infancy and does not have
much popularity (it has never been announced to anyone). As such, I feel that
commit messages will serve my purpose as useful journal entries regarding the
status of the project. They will also be interesting easter eggs for those who
would wish to seek them out for additional perspective on the project. (Granted,
one could easy script the discovery of such entries by examining the absurd
length of the commit message...perhaps the git log manpages would be useful).
So. Let's get back to the project.
ease.js is currently going through a strong refactoring in order to address
design issues that have begun to creep up as the project grew. The initial
design was a very simple one - a "series of modules", as it was originally
described in a CommonJS sense, that would provide features of a classical
Object-Oriented system. It would seem ironic that, having a focus on
classical Object-Oriented development, one would avoid developing the project in
such a paradigm. Instead, I wished to keep the design simple (because the
project seemed simple), more natural to JS developers (prototypal) and
performant (object literals do not have the overhead of instantiation). Well,
unfortunately, the project scope has increased drastically due to the success of
the implementation (and my playfulness), the chosen paradigm has become awkward
in itself and the performance benefit is indeed a micro-optimization when
compared with the performance of both the rest of the system and the system that
will implement ease.js as a framework.
You can only put off refactoring for so long before the system begins to trip
over itself and stop being a pleasure to work with. In fact, it's a slap in the
face. You develop this intricate and beautiful system (speaking collectively and
generally, of course) and it begins to feel tainted. In order to prevent it from
developing into a ball of mud - a truly unmaintainable mess - the act of
refactoring is inevitable, especially if we want to ensure that the project
survives and is actively developed for any length of time.
In this case, the glaring problem is that each of the modules are terribly,
tightly coupled. This reduces the flexibility of the system and forces us to
resort to a system riddled with conditionals. This becomes increasingly apparent
when we need to provide slightly different implementations between environments
(e.g. ES5/pre-ES5, production/development, etc and every combination).
Therefore, we need to decouple the modules in order to take advantage of
composition in order to provide more flexible feature sets depending on
environment.
What does this mean?
We need to move from object literals for the modules to prototypes (class-like,
but remember that ease.js exists because JS does not have "classes"). A number
of other prototypes can be extracted from the existing modules and abstracted to
the point where they can be appropriately injected where necessary. Rather than
using conditions for features such as fallbacks, we can encapsulate the entire
system in a facade that contains the features relevant to that particular
environment. This will also have the consequence that we can once again test
individual units rather than systems.
At the point of this commit (this entry was written before any work was done),
the major hurdle is refactoring the test cases so that they do not depend on
fallback logic and instead simply test specific units and skip the test if the
unit (the prototype) is not supported by the environment (e.g. proxies in a
pre-ES5 environment). This will allow us to finish refactoring the fallback and
environment-specific logic. It will also allow us to cleanly specify a fallback
implementation (through composition) in an ES5 environment while keeping ES5
detection mechanisms separate.
The remaining refactorings will likely be progressive. This all stemmed out of
the desire to add the method hiding feature, whose implementation varies
depending on environment. I want to get back to developing that feature so I can
get the first release (v0.1.0) out. Refactoring can continue after that point.
This project needs a version number so it can be used reliably.
2011-10-10 23:25:23 -04:00
|
|
|
|
2011-10-21 10:23:56 -04:00
|
|
|
var assert = require( 'assert' ),
|
|
|
|
assert_wrapped = {},
|
2011-11-02 23:28:23 -04:00
|
|
|
acount = 0,
|
2011-11-03 22:25:00 -04:00
|
|
|
icount = 0,
|
2011-12-10 11:06:34 -05:00
|
|
|
scount = 0,
|
2011-11-19 14:15:31 -05:00
|
|
|
skpcount = 0,
|
|
|
|
tcount = 0,
|
2011-11-02 23:28:23 -04:00
|
|
|
|
2011-11-03 21:23:40 -04:00
|
|
|
// when set to true, final statistics will be buffered until suite ends
|
|
|
|
suite = false,
|
|
|
|
failures = [],
|
|
|
|
|
2011-11-05 09:38:57 -04:00
|
|
|
// dummy object to be thrown for test skipping
|
|
|
|
SkipTest = { skip: true },
|
|
|
|
|
2011-11-02 23:28:23 -04:00
|
|
|
common_require = require( __dirname + '/common' ).require
|
|
|
|
;
|
2011-10-21 10:23:56 -04:00
|
|
|
|
|
|
|
|
|
|
|
// wrap each of the assertions so that we can keep track of the number of times
|
|
|
|
// that they were invoked
|
2011-12-10 11:06:34 -05:00
|
|
|
for ( var f in assert )
|
2011-10-21 10:23:56 -04:00
|
|
|
{
|
|
|
|
var _assert_cur = assert[ f ];
|
|
|
|
|
|
|
|
if ( typeof _assert_cur !== 'function' )
|
|
|
|
{
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// wrap the assertion to keep count
|
|
|
|
assert_wrapped[ f ] = ( function( a )
|
|
|
|
{
|
|
|
|
return function()
|
|
|
|
{
|
2011-10-21 10:27:37 -04:00
|
|
|
incAssertCount();
|
2011-10-21 10:23:56 -04:00
|
|
|
a.apply( this, arguments );
|
|
|
|
};
|
|
|
|
} )( _assert_cur );
|
|
|
|
}
|
Added very basic formatted output and failure tolerance for test case
The one year anniversary of the beginning of the ease.js project is quickly
approaching. I find myself to be not quite where I had expected many months ago,
but find that the project has evolved so much further than I had event
originally anticipated. My main motivation behind the project continues to be
making my life at work easier, while providing an excellent library that others
can hopefully benefit from. If anything, it's a fascinating experiment and
clever hack around JavaScript.
Now I find myself with a newborn child (nearly four weeks old), who demands my
constant attention (and indeed, it is difficult to find the desire to put my
attention elsewhere). Still - I am a hacker. Software is my passion. So the
project must move forward.
I also find myself unwilling to create a blog for ease.js. I feel it's
inappropriate for a project that's in its (relative) infancy and does not have
much popularity (it has never been announced to anyone). As such, I feel that
commit messages will serve my purpose as useful journal entries regarding the
status of the project. They will also be interesting easter eggs for those who
would wish to seek them out for additional perspective on the project. (Granted,
one could easy script the discovery of such entries by examining the absurd
length of the commit message...perhaps the git log manpages would be useful).
So. Let's get back to the project.
ease.js is currently going through a strong refactoring in order to address
design issues that have begun to creep up as the project grew. The initial
design was a very simple one - a "series of modules", as it was originally
described in a CommonJS sense, that would provide features of a classical
Object-Oriented system. It would seem ironic that, having a focus on
classical Object-Oriented development, one would avoid developing the project in
such a paradigm. Instead, I wished to keep the design simple (because the
project seemed simple), more natural to JS developers (prototypal) and
performant (object literals do not have the overhead of instantiation). Well,
unfortunately, the project scope has increased drastically due to the success of
the implementation (and my playfulness), the chosen paradigm has become awkward
in itself and the performance benefit is indeed a micro-optimization when
compared with the performance of both the rest of the system and the system that
will implement ease.js as a framework.
You can only put off refactoring for so long before the system begins to trip
over itself and stop being a pleasure to work with. In fact, it's a slap in the
face. You develop this intricate and beautiful system (speaking collectively and
generally, of course) and it begins to feel tainted. In order to prevent it from
developing into a ball of mud - a truly unmaintainable mess - the act of
refactoring is inevitable, especially if we want to ensure that the project
survives and is actively developed for any length of time.
In this case, the glaring problem is that each of the modules are terribly,
tightly coupled. This reduces the flexibility of the system and forces us to
resort to a system riddled with conditionals. This becomes increasingly apparent
when we need to provide slightly different implementations between environments
(e.g. ES5/pre-ES5, production/development, etc and every combination).
Therefore, we need to decouple the modules in order to take advantage of
composition in order to provide more flexible feature sets depending on
environment.
What does this mean?
We need to move from object literals for the modules to prototypes (class-like,
but remember that ease.js exists because JS does not have "classes"). A number
of other prototypes can be extracted from the existing modules and abstracted to
the point where they can be appropriately injected where necessary. Rather than
using conditions for features such as fallbacks, we can encapsulate the entire
system in a facade that contains the features relevant to that particular
environment. This will also have the consequence that we can once again test
individual units rather than systems.
At the point of this commit (this entry was written before any work was done),
the major hurdle is refactoring the test cases so that they do not depend on
fallback logic and instead simply test specific units and skip the test if the
unit (the prototype) is not supported by the environment (e.g. proxies in a
pre-ES5 environment). This will allow us to finish refactoring the fallback and
environment-specific logic. It will also allow us to cleanly specify a fallback
implementation (through composition) in an ES5 environment while keeping ES5
detection mechanisms separate.
The remaining refactorings will likely be progressive. This all stemmed out of
the desire to add the method hiding feature, whose implementation varies
depending on environment. I want to get back to developing that feature so I can
get the first release (v0.1.0) out. Refactoring can continue after that point.
This project needs a version number so it can be used reliably.
2011-10-10 23:25:23 -04:00
|
|
|
|
|
|
|
|
2011-10-21 10:27:37 -04:00
|
|
|
function incAssertCount()
|
|
|
|
{
|
|
|
|
acount++;
|
|
|
|
};
|
|
|
|
|
|
|
|
|
Added very basic formatted output and failure tolerance for test case
The one year anniversary of the beginning of the ease.js project is quickly
approaching. I find myself to be not quite where I had expected many months ago,
but find that the project has evolved so much further than I had event
originally anticipated. My main motivation behind the project continues to be
making my life at work easier, while providing an excellent library that others
can hopefully benefit from. If anything, it's a fascinating experiment and
clever hack around JavaScript.
Now I find myself with a newborn child (nearly four weeks old), who demands my
constant attention (and indeed, it is difficult to find the desire to put my
attention elsewhere). Still - I am a hacker. Software is my passion. So the
project must move forward.
I also find myself unwilling to create a blog for ease.js. I feel it's
inappropriate for a project that's in its (relative) infancy and does not have
much popularity (it has never been announced to anyone). As such, I feel that
commit messages will serve my purpose as useful journal entries regarding the
status of the project. They will also be interesting easter eggs for those who
would wish to seek them out for additional perspective on the project. (Granted,
one could easy script the discovery of such entries by examining the absurd
length of the commit message...perhaps the git log manpages would be useful).
So. Let's get back to the project.
ease.js is currently going through a strong refactoring in order to address
design issues that have begun to creep up as the project grew. The initial
design was a very simple one - a "series of modules", as it was originally
described in a CommonJS sense, that would provide features of a classical
Object-Oriented system. It would seem ironic that, having a focus on
classical Object-Oriented development, one would avoid developing the project in
such a paradigm. Instead, I wished to keep the design simple (because the
project seemed simple), more natural to JS developers (prototypal) and
performant (object literals do not have the overhead of instantiation). Well,
unfortunately, the project scope has increased drastically due to the success of
the implementation (and my playfulness), the chosen paradigm has become awkward
in itself and the performance benefit is indeed a micro-optimization when
compared with the performance of both the rest of the system and the system that
will implement ease.js as a framework.
You can only put off refactoring for so long before the system begins to trip
over itself and stop being a pleasure to work with. In fact, it's a slap in the
face. You develop this intricate and beautiful system (speaking collectively and
generally, of course) and it begins to feel tainted. In order to prevent it from
developing into a ball of mud - a truly unmaintainable mess - the act of
refactoring is inevitable, especially if we want to ensure that the project
survives and is actively developed for any length of time.
In this case, the glaring problem is that each of the modules are terribly,
tightly coupled. This reduces the flexibility of the system and forces us to
resort to a system riddled with conditionals. This becomes increasingly apparent
when we need to provide slightly different implementations between environments
(e.g. ES5/pre-ES5, production/development, etc and every combination).
Therefore, we need to decouple the modules in order to take advantage of
composition in order to provide more flexible feature sets depending on
environment.
What does this mean?
We need to move from object literals for the modules to prototypes (class-like,
but remember that ease.js exists because JS does not have "classes"). A number
of other prototypes can be extracted from the existing modules and abstracted to
the point where they can be appropriately injected where necessary. Rather than
using conditions for features such as fallbacks, we can encapsulate the entire
system in a facade that contains the features relevant to that particular
environment. This will also have the consequence that we can once again test
individual units rather than systems.
At the point of this commit (this entry was written before any work was done),
the major hurdle is refactoring the test cases so that they do not depend on
fallback logic and instead simply test specific units and skip the test if the
unit (the prototype) is not supported by the environment (e.g. proxies in a
pre-ES5 environment). This will allow us to finish refactoring the fallback and
environment-specific logic. It will also allow us to cleanly specify a fallback
implementation (through composition) in an ES5 environment while keeping ES5
detection mechanisms separate.
The remaining refactorings will likely be progressive. This all stemmed out of
the desire to add the method hiding feature, whose implementation varies
depending on environment. I want to get back to developing that feature so I can
get the first release (v0.1.0) out. Refactoring can continue after that point.
This project needs a version number so it can be used reliably.
2011-10-10 23:25:23 -04:00
|
|
|
/**
|
|
|
|
* Defines and runs a test case
|
|
|
|
*
|
|
|
|
* This is a very basic system that provides a more familiar jUnit/phpUnit-style
|
|
|
|
* output for xUnit tests and allows all tests in the case to be run in the
|
|
|
|
* event of a test failure.
|
|
|
|
*
|
|
|
|
* The test name should be given as the key and the test itself as a function as
|
|
|
|
* the value. The test will be invoked within the context of the assertion
|
|
|
|
* module.
|
|
|
|
*
|
|
|
|
* This will be evolving throughout the life of the project. Mainly, it cannot
|
|
|
|
* be run as part of a suite without multiple summary outputs.
|
|
|
|
*
|
|
|
|
* @param {Object.<string,function()>} object containing tests
|
|
|
|
*
|
|
|
|
* @return {undefined}
|
|
|
|
*/
|
|
|
|
module.exports = function( test_case )
|
|
|
|
{
|
2011-11-03 21:23:40 -04:00
|
|
|
var context = prepareCaseContext(),
|
2011-11-19 14:09:23 -05:00
|
|
|
setUp = test_case.setUp;
|
Added very basic formatted output and failure tolerance for test case
The one year anniversary of the beginning of the ease.js project is quickly
approaching. I find myself to be not quite where I had expected many months ago,
but find that the project has evolved so much further than I had event
originally anticipated. My main motivation behind the project continues to be
making my life at work easier, while providing an excellent library that others
can hopefully benefit from. If anything, it's a fascinating experiment and
clever hack around JavaScript.
Now I find myself with a newborn child (nearly four weeks old), who demands my
constant attention (and indeed, it is difficult to find the desire to put my
attention elsewhere). Still - I am a hacker. Software is my passion. So the
project must move forward.
I also find myself unwilling to create a blog for ease.js. I feel it's
inappropriate for a project that's in its (relative) infancy and does not have
much popularity (it has never been announced to anyone). As such, I feel that
commit messages will serve my purpose as useful journal entries regarding the
status of the project. They will also be interesting easter eggs for those who
would wish to seek them out for additional perspective on the project. (Granted,
one could easy script the discovery of such entries by examining the absurd
length of the commit message...perhaps the git log manpages would be useful).
So. Let's get back to the project.
ease.js is currently going through a strong refactoring in order to address
design issues that have begun to creep up as the project grew. The initial
design was a very simple one - a "series of modules", as it was originally
described in a CommonJS sense, that would provide features of a classical
Object-Oriented system. It would seem ironic that, having a focus on
classical Object-Oriented development, one would avoid developing the project in
such a paradigm. Instead, I wished to keep the design simple (because the
project seemed simple), more natural to JS developers (prototypal) and
performant (object literals do not have the overhead of instantiation). Well,
unfortunately, the project scope has increased drastically due to the success of
the implementation (and my playfulness), the chosen paradigm has become awkward
in itself and the performance benefit is indeed a micro-optimization when
compared with the performance of both the rest of the system and the system that
will implement ease.js as a framework.
You can only put off refactoring for so long before the system begins to trip
over itself and stop being a pleasure to work with. In fact, it's a slap in the
face. You develop this intricate and beautiful system (speaking collectively and
generally, of course) and it begins to feel tainted. In order to prevent it from
developing into a ball of mud - a truly unmaintainable mess - the act of
refactoring is inevitable, especially if we want to ensure that the project
survives and is actively developed for any length of time.
In this case, the glaring problem is that each of the modules are terribly,
tightly coupled. This reduces the flexibility of the system and forces us to
resort to a system riddled with conditionals. This becomes increasingly apparent
when we need to provide slightly different implementations between environments
(e.g. ES5/pre-ES5, production/development, etc and every combination).
Therefore, we need to decouple the modules in order to take advantage of
composition in order to provide more flexible feature sets depending on
environment.
What does this mean?
We need to move from object literals for the modules to prototypes (class-like,
but remember that ease.js exists because JS does not have "classes"). A number
of other prototypes can be extracted from the existing modules and abstracted to
the point where they can be appropriately injected where necessary. Rather than
using conditions for features such as fallbacks, we can encapsulate the entire
system in a facade that contains the features relevant to that particular
environment. This will also have the consequence that we can once again test
individual units rather than systems.
At the point of this commit (this entry was written before any work was done),
the major hurdle is refactoring the test cases so that they do not depend on
fallback logic and instead simply test specific units and skip the test if the
unit (the prototype) is not supported by the environment (e.g. proxies in a
pre-ES5 environment). This will allow us to finish refactoring the fallback and
environment-specific logic. It will also allow us to cleanly specify a fallback
implementation (through composition) in an ES5 environment while keeping ES5
detection mechanisms separate.
The remaining refactorings will likely be progressive. This all stemmed out of
the desire to add the method hiding feature, whose implementation varies
depending on environment. I want to get back to developing that feature so I can
get the first release (v0.1.0) out. Refactoring can continue after that point.
This project needs a version number so it can be used reliably.
2011-10-10 23:25:23 -04:00
|
|
|
|
2011-11-03 21:23:40 -04:00
|
|
|
// if we're not running a suite, clear out the failures
|
|
|
|
if ( !( suite ) )
|
|
|
|
{
|
|
|
|
init();
|
|
|
|
}
|
2011-10-21 10:23:56 -04:00
|
|
|
|
2011-10-21 09:51:42 -04:00
|
|
|
// perform case-wide setup
|
|
|
|
test_case.caseSetUp && test_case.caseSetUp.call( context );
|
|
|
|
|
|
|
|
// remove unneeded methods so we don't invoke them as tests below
|
|
|
|
delete test_case.caseSetUp;
|
Added very basic formatted output and failure tolerance for test case
The one year anniversary of the beginning of the ease.js project is quickly
approaching. I find myself to be not quite where I had expected many months ago,
but find that the project has evolved so much further than I had event
originally anticipated. My main motivation behind the project continues to be
making my life at work easier, while providing an excellent library that others
can hopefully benefit from. If anything, it's a fascinating experiment and
clever hack around JavaScript.
Now I find myself with a newborn child (nearly four weeks old), who demands my
constant attention (and indeed, it is difficult to find the desire to put my
attention elsewhere). Still - I am a hacker. Software is my passion. So the
project must move forward.
I also find myself unwilling to create a blog for ease.js. I feel it's
inappropriate for a project that's in its (relative) infancy and does not have
much popularity (it has never been announced to anyone). As such, I feel that
commit messages will serve my purpose as useful journal entries regarding the
status of the project. They will also be interesting easter eggs for those who
would wish to seek them out for additional perspective on the project. (Granted,
one could easy script the discovery of such entries by examining the absurd
length of the commit message...perhaps the git log manpages would be useful).
So. Let's get back to the project.
ease.js is currently going through a strong refactoring in order to address
design issues that have begun to creep up as the project grew. The initial
design was a very simple one - a "series of modules", as it was originally
described in a CommonJS sense, that would provide features of a classical
Object-Oriented system. It would seem ironic that, having a focus on
classical Object-Oriented development, one would avoid developing the project in
such a paradigm. Instead, I wished to keep the design simple (because the
project seemed simple), more natural to JS developers (prototypal) and
performant (object literals do not have the overhead of instantiation). Well,
unfortunately, the project scope has increased drastically due to the success of
the implementation (and my playfulness), the chosen paradigm has become awkward
in itself and the performance benefit is indeed a micro-optimization when
compared with the performance of both the rest of the system and the system that
will implement ease.js as a framework.
You can only put off refactoring for so long before the system begins to trip
over itself and stop being a pleasure to work with. In fact, it's a slap in the
face. You develop this intricate and beautiful system (speaking collectively and
generally, of course) and it begins to feel tainted. In order to prevent it from
developing into a ball of mud - a truly unmaintainable mess - the act of
refactoring is inevitable, especially if we want to ensure that the project
survives and is actively developed for any length of time.
In this case, the glaring problem is that each of the modules are terribly,
tightly coupled. This reduces the flexibility of the system and forces us to
resort to a system riddled with conditionals. This becomes increasingly apparent
when we need to provide slightly different implementations between environments
(e.g. ES5/pre-ES5, production/development, etc and every combination).
Therefore, we need to decouple the modules in order to take advantage of
composition in order to provide more flexible feature sets depending on
environment.
What does this mean?
We need to move from object literals for the modules to prototypes (class-like,
but remember that ease.js exists because JS does not have "classes"). A number
of other prototypes can be extracted from the existing modules and abstracted to
the point where they can be appropriately injected where necessary. Rather than
using conditions for features such as fallbacks, we can encapsulate the entire
system in a facade that contains the features relevant to that particular
environment. This will also have the consequence that we can once again test
individual units rather than systems.
At the point of this commit (this entry was written before any work was done),
the major hurdle is refactoring the test cases so that they do not depend on
fallback logic and instead simply test specific units and skip the test if the
unit (the prototype) is not supported by the environment (e.g. proxies in a
pre-ES5 environment). This will allow us to finish refactoring the fallback and
environment-specific logic. It will also allow us to cleanly specify a fallback
implementation (through composition) in an ES5 environment while keeping ES5
detection mechanisms separate.
The remaining refactorings will likely be progressive. This all stemmed out of
the desire to add the method hiding feature, whose implementation varies
depending on environment. I want to get back to developing that feature so I can
get the first release (v0.1.0) out. Refactoring can continue after that point.
This project needs a version number so it can be used reliably.
2011-10-10 23:25:23 -04:00
|
|
|
delete test_case.setUp;
|
|
|
|
|
|
|
|
// run each test in the case
|
2011-12-10 11:06:34 -05:00
|
|
|
for ( var test in test_case )
|
Added very basic formatted output and failure tolerance for test case
The one year anniversary of the beginning of the ease.js project is quickly
approaching. I find myself to be not quite where I had expected many months ago,
but find that the project has evolved so much further than I had event
originally anticipated. My main motivation behind the project continues to be
making my life at work easier, while providing an excellent library that others
can hopefully benefit from. If anything, it's a fascinating experiment and
clever hack around JavaScript.
Now I find myself with a newborn child (nearly four weeks old), who demands my
constant attention (and indeed, it is difficult to find the desire to put my
attention elsewhere). Still - I am a hacker. Software is my passion. So the
project must move forward.
I also find myself unwilling to create a blog for ease.js. I feel it's
inappropriate for a project that's in its (relative) infancy and does not have
much popularity (it has never been announced to anyone). As such, I feel that
commit messages will serve my purpose as useful journal entries regarding the
status of the project. They will also be interesting easter eggs for those who
would wish to seek them out for additional perspective on the project. (Granted,
one could easy script the discovery of such entries by examining the absurd
length of the commit message...perhaps the git log manpages would be useful).
So. Let's get back to the project.
ease.js is currently going through a strong refactoring in order to address
design issues that have begun to creep up as the project grew. The initial
design was a very simple one - a "series of modules", as it was originally
described in a CommonJS sense, that would provide features of a classical
Object-Oriented system. It would seem ironic that, having a focus on
classical Object-Oriented development, one would avoid developing the project in
such a paradigm. Instead, I wished to keep the design simple (because the
project seemed simple), more natural to JS developers (prototypal) and
performant (object literals do not have the overhead of instantiation). Well,
unfortunately, the project scope has increased drastically due to the success of
the implementation (and my playfulness), the chosen paradigm has become awkward
in itself and the performance benefit is indeed a micro-optimization when
compared with the performance of both the rest of the system and the system that
will implement ease.js as a framework.
You can only put off refactoring for so long before the system begins to trip
over itself and stop being a pleasure to work with. In fact, it's a slap in the
face. You develop this intricate and beautiful system (speaking collectively and
generally, of course) and it begins to feel tainted. In order to prevent it from
developing into a ball of mud - a truly unmaintainable mess - the act of
refactoring is inevitable, especially if we want to ensure that the project
survives and is actively developed for any length of time.
In this case, the glaring problem is that each of the modules are terribly,
tightly coupled. This reduces the flexibility of the system and forces us to
resort to a system riddled with conditionals. This becomes increasingly apparent
when we need to provide slightly different implementations between environments
(e.g. ES5/pre-ES5, production/development, etc and every combination).
Therefore, we need to decouple the modules in order to take advantage of
composition in order to provide more flexible feature sets depending on
environment.
What does this mean?
We need to move from object literals for the modules to prototypes (class-like,
but remember that ease.js exists because JS does not have "classes"). A number
of other prototypes can be extracted from the existing modules and abstracted to
the point where they can be appropriately injected where necessary. Rather than
using conditions for features such as fallbacks, we can encapsulate the entire
system in a facade that contains the features relevant to that particular
environment. This will also have the consequence that we can once again test
individual units rather than systems.
At the point of this commit (this entry was written before any work was done),
the major hurdle is refactoring the test cases so that they do not depend on
fallback logic and instead simply test specific units and skip the test if the
unit (the prototype) is not supported by the environment (e.g. proxies in a
pre-ES5 environment). This will allow us to finish refactoring the fallback and
environment-specific logic. It will also allow us to cleanly specify a fallback
implementation (through composition) in an ES5 environment while keeping ES5
detection mechanisms separate.
The remaining refactorings will likely be progressive. This all stemmed out of
the desire to add the method hiding feature, whose implementation varies
depending on environment. I want to get back to developing that feature so I can
get the first release (v0.1.0) out. Refactoring can continue after that point.
This project needs a version number so it can be used reliably.
2011-10-10 23:25:23 -04:00
|
|
|
{
|
2011-11-19 14:09:23 -05:00
|
|
|
var data = test.match( /^(?:@(.*?)\((.*?)\))?(.*)$/ ),
|
|
|
|
method = data[ 1 ],
|
|
|
|
prop = data[ 2 ],
|
|
|
|
name = data[ 3 ],
|
|
|
|
count = 1,
|
|
|
|
args = [ [] ]
|
|
|
|
;
|
2011-11-03 22:25:00 -04:00
|
|
|
|
2011-11-19 14:09:23 -05:00
|
|
|
if ( method === 'each' )
|
Added very basic formatted output and failure tolerance for test case
The one year anniversary of the beginning of the ease.js project is quickly
approaching. I find myself to be not quite where I had expected many months ago,
but find that the project has evolved so much further than I had event
originally anticipated. My main motivation behind the project continues to be
making my life at work easier, while providing an excellent library that others
can hopefully benefit from. If anything, it's a fascinating experiment and
clever hack around JavaScript.
Now I find myself with a newborn child (nearly four weeks old), who demands my
constant attention (and indeed, it is difficult to find the desire to put my
attention elsewhere). Still - I am a hacker. Software is my passion. So the
project must move forward.
I also find myself unwilling to create a blog for ease.js. I feel it's
inappropriate for a project that's in its (relative) infancy and does not have
much popularity (it has never been announced to anyone). As such, I feel that
commit messages will serve my purpose as useful journal entries regarding the
status of the project. They will also be interesting easter eggs for those who
would wish to seek them out for additional perspective on the project. (Granted,
one could easy script the discovery of such entries by examining the absurd
length of the commit message...perhaps the git log manpages would be useful).
So. Let's get back to the project.
ease.js is currently going through a strong refactoring in order to address
design issues that have begun to creep up as the project grew. The initial
design was a very simple one - a "series of modules", as it was originally
described in a CommonJS sense, that would provide features of a classical
Object-Oriented system. It would seem ironic that, having a focus on
classical Object-Oriented development, one would avoid developing the project in
such a paradigm. Instead, I wished to keep the design simple (because the
project seemed simple), more natural to JS developers (prototypal) and
performant (object literals do not have the overhead of instantiation). Well,
unfortunately, the project scope has increased drastically due to the success of
the implementation (and my playfulness), the chosen paradigm has become awkward
in itself and the performance benefit is indeed a micro-optimization when
compared with the performance of both the rest of the system and the system that
will implement ease.js as a framework.
You can only put off refactoring for so long before the system begins to trip
over itself and stop being a pleasure to work with. In fact, it's a slap in the
face. You develop this intricate and beautiful system (speaking collectively and
generally, of course) and it begins to feel tainted. In order to prevent it from
developing into a ball of mud - a truly unmaintainable mess - the act of
refactoring is inevitable, especially if we want to ensure that the project
survives and is actively developed for any length of time.
In this case, the glaring problem is that each of the modules are terribly,
tightly coupled. This reduces the flexibility of the system and forces us to
resort to a system riddled with conditionals. This becomes increasingly apparent
when we need to provide slightly different implementations between environments
(e.g. ES5/pre-ES5, production/development, etc and every combination).
Therefore, we need to decouple the modules in order to take advantage of
composition in order to provide more flexible feature sets depending on
environment.
What does this mean?
We need to move from object literals for the modules to prototypes (class-like,
but remember that ease.js exists because JS does not have "classes"). A number
of other prototypes can be extracted from the existing modules and abstracted to
the point where they can be appropriately injected where necessary. Rather than
using conditions for features such as fallbacks, we can encapsulate the entire
system in a facade that contains the features relevant to that particular
environment. This will also have the consequence that we can once again test
individual units rather than systems.
At the point of this commit (this entry was written before any work was done),
the major hurdle is refactoring the test cases so that they do not depend on
fallback logic and instead simply test specific units and skip the test if the
unit (the prototype) is not supported by the environment (e.g. proxies in a
pre-ES5 environment). This will allow us to finish refactoring the fallback and
environment-specific logic. It will also allow us to cleanly specify a fallback
implementation (through composition) in an ES5 environment while keeping ES5
detection mechanisms separate.
The remaining refactorings will likely be progressive. This all stemmed out of
the desire to add the method hiding feature, whose implementation varies
depending on environment. I want to get back to developing that feature so I can
get the first release (v0.1.0) out. Refactoring can continue after that point.
This project needs a version number so it can be used reliably.
2011-10-10 23:25:23 -04:00
|
|
|
{
|
2011-11-19 14:09:23 -05:00
|
|
|
count = context[ prop ].length;
|
|
|
|
args = [];
|
Added very basic formatted output and failure tolerance for test case
The one year anniversary of the beginning of the ease.js project is quickly
approaching. I find myself to be not quite where I had expected many months ago,
but find that the project has evolved so much further than I had event
originally anticipated. My main motivation behind the project continues to be
making my life at work easier, while providing an excellent library that others
can hopefully benefit from. If anything, it's a fascinating experiment and
clever hack around JavaScript.
Now I find myself with a newborn child (nearly four weeks old), who demands my
constant attention (and indeed, it is difficult to find the desire to put my
attention elsewhere). Still - I am a hacker. Software is my passion. So the
project must move forward.
I also find myself unwilling to create a blog for ease.js. I feel it's
inappropriate for a project that's in its (relative) infancy and does not have
much popularity (it has never been announced to anyone). As such, I feel that
commit messages will serve my purpose as useful journal entries regarding the
status of the project. They will also be interesting easter eggs for those who
would wish to seek them out for additional perspective on the project. (Granted,
one could easy script the discovery of such entries by examining the absurd
length of the commit message...perhaps the git log manpages would be useful).
So. Let's get back to the project.
ease.js is currently going through a strong refactoring in order to address
design issues that have begun to creep up as the project grew. The initial
design was a very simple one - a "series of modules", as it was originally
described in a CommonJS sense, that would provide features of a classical
Object-Oriented system. It would seem ironic that, having a focus on
classical Object-Oriented development, one would avoid developing the project in
such a paradigm. Instead, I wished to keep the design simple (because the
project seemed simple), more natural to JS developers (prototypal) and
performant (object literals do not have the overhead of instantiation). Well,
unfortunately, the project scope has increased drastically due to the success of
the implementation (and my playfulness), the chosen paradigm has become awkward
in itself and the performance benefit is indeed a micro-optimization when
compared with the performance of both the rest of the system and the system that
will implement ease.js as a framework.
You can only put off refactoring for so long before the system begins to trip
over itself and stop being a pleasure to work with. In fact, it's a slap in the
face. You develop this intricate and beautiful system (speaking collectively and
generally, of course) and it begins to feel tainted. In order to prevent it from
developing into a ball of mud - a truly unmaintainable mess - the act of
refactoring is inevitable, especially if we want to ensure that the project
survives and is actively developed for any length of time.
In this case, the glaring problem is that each of the modules are terribly,
tightly coupled. This reduces the flexibility of the system and forces us to
resort to a system riddled with conditionals. This becomes increasingly apparent
when we need to provide slightly different implementations between environments
(e.g. ES5/pre-ES5, production/development, etc and every combination).
Therefore, we need to decouple the modules in order to take advantage of
composition in order to provide more flexible feature sets depending on
environment.
What does this mean?
We need to move from object literals for the modules to prototypes (class-like,
but remember that ease.js exists because JS does not have "classes"). A number
of other prototypes can be extracted from the existing modules and abstracted to
the point where they can be appropriately injected where necessary. Rather than
using conditions for features such as fallbacks, we can encapsulate the entire
system in a facade that contains the features relevant to that particular
environment. This will also have the consequence that we can once again test
individual units rather than systems.
At the point of this commit (this entry was written before any work was done),
the major hurdle is refactoring the test cases so that they do not depend on
fallback logic and instead simply test specific units and skip the test if the
unit (the prototype) is not supported by the environment (e.g. proxies in a
pre-ES5 environment). This will allow us to finish refactoring the fallback and
environment-specific logic. It will also allow us to cleanly specify a fallback
implementation (through composition) in an ES5 environment while keeping ES5
detection mechanisms separate.
The remaining refactorings will likely be progressive. This all stemmed out of
the desire to add the method hiding feature, whose implementation varies
depending on environment. I want to get back to developing that feature so I can
get the first release (v0.1.0) out. Refactoring can continue after that point.
This project needs a version number so it can be used reliably.
2011-10-10 23:25:23 -04:00
|
|
|
|
2011-11-19 14:09:23 -05:00
|
|
|
for ( var i = 0; i < count; i++ )
|
2011-11-03 22:25:00 -04:00
|
|
|
{
|
2011-11-19 14:09:23 -05:00
|
|
|
args.push( [ context[ prop ][ i ] ] );
|
2011-11-03 22:25:00 -04:00
|
|
|
}
|
Added very basic formatted output and failure tolerance for test case
The one year anniversary of the beginning of the ease.js project is quickly
approaching. I find myself to be not quite where I had expected many months ago,
but find that the project has evolved so much further than I had event
originally anticipated. My main motivation behind the project continues to be
making my life at work easier, while providing an excellent library that others
can hopefully benefit from. If anything, it's a fascinating experiment and
clever hack around JavaScript.
Now I find myself with a newborn child (nearly four weeks old), who demands my
constant attention (and indeed, it is difficult to find the desire to put my
attention elsewhere). Still - I am a hacker. Software is my passion. So the
project must move forward.
I also find myself unwilling to create a blog for ease.js. I feel it's
inappropriate for a project that's in its (relative) infancy and does not have
much popularity (it has never been announced to anyone). As such, I feel that
commit messages will serve my purpose as useful journal entries regarding the
status of the project. They will also be interesting easter eggs for those who
would wish to seek them out for additional perspective on the project. (Granted,
one could easy script the discovery of such entries by examining the absurd
length of the commit message...perhaps the git log manpages would be useful).
So. Let's get back to the project.
ease.js is currently going through a strong refactoring in order to address
design issues that have begun to creep up as the project grew. The initial
design was a very simple one - a "series of modules", as it was originally
described in a CommonJS sense, that would provide features of a classical
Object-Oriented system. It would seem ironic that, having a focus on
classical Object-Oriented development, one would avoid developing the project in
such a paradigm. Instead, I wished to keep the design simple (because the
project seemed simple), more natural to JS developers (prototypal) and
performant (object literals do not have the overhead of instantiation). Well,
unfortunately, the project scope has increased drastically due to the success of
the implementation (and my playfulness), the chosen paradigm has become awkward
in itself and the performance benefit is indeed a micro-optimization when
compared with the performance of both the rest of the system and the system that
will implement ease.js as a framework.
You can only put off refactoring for so long before the system begins to trip
over itself and stop being a pleasure to work with. In fact, it's a slap in the
face. You develop this intricate and beautiful system (speaking collectively and
generally, of course) and it begins to feel tainted. In order to prevent it from
developing into a ball of mud - a truly unmaintainable mess - the act of
refactoring is inevitable, especially if we want to ensure that the project
survives and is actively developed for any length of time.
In this case, the glaring problem is that each of the modules are terribly,
tightly coupled. This reduces the flexibility of the system and forces us to
resort to a system riddled with conditionals. This becomes increasingly apparent
when we need to provide slightly different implementations between environments
(e.g. ES5/pre-ES5, production/development, etc and every combination).
Therefore, we need to decouple the modules in order to take advantage of
composition in order to provide more flexible feature sets depending on
environment.
What does this mean?
We need to move from object literals for the modules to prototypes (class-like,
but remember that ease.js exists because JS does not have "classes"). A number
of other prototypes can be extracted from the existing modules and abstracted to
the point where they can be appropriately injected where necessary. Rather than
using conditions for features such as fallbacks, we can encapsulate the entire
system in a facade that contains the features relevant to that particular
environment. This will also have the consequence that we can once again test
individual units rather than systems.
At the point of this commit (this entry was written before any work was done),
the major hurdle is refactoring the test cases so that they do not depend on
fallback logic and instead simply test specific units and skip the test if the
unit (the prototype) is not supported by the environment (e.g. proxies in a
pre-ES5 environment). This will allow us to finish refactoring the fallback and
environment-specific logic. It will also allow us to cleanly specify a fallback
implementation (through composition) in an ES5 environment while keeping ES5
detection mechanisms separate.
The remaining refactorings will likely be progressive. This all stemmed out of
the desire to add the method hiding feature, whose implementation varies
depending on environment. I want to get back to developing that feature so I can
get the first release (v0.1.0) out. Refactoring can continue after that point.
This project needs a version number so it can be used reliably.
2011-10-10 23:25:23 -04:00
|
|
|
}
|
2011-11-20 20:37:59 -05:00
|
|
|
else if ( method )
|
Added very basic formatted output and failure tolerance for test case
The one year anniversary of the beginning of the ease.js project is quickly
approaching. I find myself to be not quite where I had expected many months ago,
but find that the project has evolved so much further than I had event
originally anticipated. My main motivation behind the project continues to be
making my life at work easier, while providing an excellent library that others
can hopefully benefit from. If anything, it's a fascinating experiment and
clever hack around JavaScript.
Now I find myself with a newborn child (nearly four weeks old), who demands my
constant attention (and indeed, it is difficult to find the desire to put my
attention elsewhere). Still - I am a hacker. Software is my passion. So the
project must move forward.
I also find myself unwilling to create a blog for ease.js. I feel it's
inappropriate for a project that's in its (relative) infancy and does not have
much popularity (it has never been announced to anyone). As such, I feel that
commit messages will serve my purpose as useful journal entries regarding the
status of the project. They will also be interesting easter eggs for those who
would wish to seek them out for additional perspective on the project. (Granted,
one could easy script the discovery of such entries by examining the absurd
length of the commit message...perhaps the git log manpages would be useful).
So. Let's get back to the project.
ease.js is currently going through a strong refactoring in order to address
design issues that have begun to creep up as the project grew. The initial
design was a very simple one - a "series of modules", as it was originally
described in a CommonJS sense, that would provide features of a classical
Object-Oriented system. It would seem ironic that, having a focus on
classical Object-Oriented development, one would avoid developing the project in
such a paradigm. Instead, I wished to keep the design simple (because the
project seemed simple), more natural to JS developers (prototypal) and
performant (object literals do not have the overhead of instantiation). Well,
unfortunately, the project scope has increased drastically due to the success of
the implementation (and my playfulness), the chosen paradigm has become awkward
in itself and the performance benefit is indeed a micro-optimization when
compared with the performance of both the rest of the system and the system that
will implement ease.js as a framework.
You can only put off refactoring for so long before the system begins to trip
over itself and stop being a pleasure to work with. In fact, it's a slap in the
face. You develop this intricate and beautiful system (speaking collectively and
generally, of course) and it begins to feel tainted. In order to prevent it from
developing into a ball of mud - a truly unmaintainable mess - the act of
refactoring is inevitable, especially if we want to ensure that the project
survives and is actively developed for any length of time.
In this case, the glaring problem is that each of the modules are terribly,
tightly coupled. This reduces the flexibility of the system and forces us to
resort to a system riddled with conditionals. This becomes increasingly apparent
when we need to provide slightly different implementations between environments
(e.g. ES5/pre-ES5, production/development, etc and every combination).
Therefore, we need to decouple the modules in order to take advantage of
composition in order to provide more flexible feature sets depending on
environment.
What does this mean?
We need to move from object literals for the modules to prototypes (class-like,
but remember that ease.js exists because JS does not have "classes"). A number
of other prototypes can be extracted from the existing modules and abstracted to
the point where they can be appropriately injected where necessary. Rather than
using conditions for features such as fallbacks, we can encapsulate the entire
system in a facade that contains the features relevant to that particular
environment. This will also have the consequence that we can once again test
individual units rather than systems.
At the point of this commit (this entry was written before any work was done),
the major hurdle is refactoring the test cases so that they do not depend on
fallback logic and instead simply test specific units and skip the test if the
unit (the prototype) is not supported by the environment (e.g. proxies in a
pre-ES5 environment). This will allow us to finish refactoring the fallback and
environment-specific logic. It will also allow us to cleanly specify a fallback
implementation (through composition) in an ES5 environment while keeping ES5
detection mechanisms separate.
The remaining refactorings will likely be progressive. This all stemmed out of
the desire to add the method hiding feature, whose implementation varies
depending on environment. I want to get back to developing that feature so I can
get the first release (v0.1.0) out. Refactoring can continue after that point.
This project needs a version number so it can be used reliably.
2011-10-10 23:25:23 -04:00
|
|
|
{
|
2011-11-19 14:09:23 -05:00
|
|
|
throw Error( "Unknown test method: " + method );
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
// perform the appropriate number of tests
|
|
|
|
for ( var i = 0; i < count; i++ )
|
|
|
|
{
|
|
|
|
tryTest(
|
|
|
|
test_case,
|
|
|
|
test,
|
2012-05-03 21:46:33 -04:00
|
|
|
( setUp || null ),
|
2011-11-19 14:09:23 -05:00
|
|
|
name + ( ( count > 1 )
|
|
|
|
? ( ' (' + i + ')' )
|
|
|
|
: ''
|
|
|
|
),
|
|
|
|
context,
|
|
|
|
args[ i ]
|
|
|
|
);
|
2011-11-19 14:15:31 -05:00
|
|
|
|
|
|
|
// output a newline and the count every 60 tests
|
|
|
|
( tcount % 60 ) || testPrint( " " + tcount + "\n" );
|
Added very basic formatted output and failure tolerance for test case
The one year anniversary of the beginning of the ease.js project is quickly
approaching. I find myself to be not quite where I had expected many months ago,
but find that the project has evolved so much further than I had event
originally anticipated. My main motivation behind the project continues to be
making my life at work easier, while providing an excellent library that others
can hopefully benefit from. If anything, it's a fascinating experiment and
clever hack around JavaScript.
Now I find myself with a newborn child (nearly four weeks old), who demands my
constant attention (and indeed, it is difficult to find the desire to put my
attention elsewhere). Still - I am a hacker. Software is my passion. So the
project must move forward.
I also find myself unwilling to create a blog for ease.js. I feel it's
inappropriate for a project that's in its (relative) infancy and does not have
much popularity (it has never been announced to anyone). As such, I feel that
commit messages will serve my purpose as useful journal entries regarding the
status of the project. They will also be interesting easter eggs for those who
would wish to seek them out for additional perspective on the project. (Granted,
one could easy script the discovery of such entries by examining the absurd
length of the commit message...perhaps the git log manpages would be useful).
So. Let's get back to the project.
ease.js is currently going through a strong refactoring in order to address
design issues that have begun to creep up as the project grew. The initial
design was a very simple one - a "series of modules", as it was originally
described in a CommonJS sense, that would provide features of a classical
Object-Oriented system. It would seem ironic that, having a focus on
classical Object-Oriented development, one would avoid developing the project in
such a paradigm. Instead, I wished to keep the design simple (because the
project seemed simple), more natural to JS developers (prototypal) and
performant (object literals do not have the overhead of instantiation). Well,
unfortunately, the project scope has increased drastically due to the success of
the implementation (and my playfulness), the chosen paradigm has become awkward
in itself and the performance benefit is indeed a micro-optimization when
compared with the performance of both the rest of the system and the system that
will implement ease.js as a framework.
You can only put off refactoring for so long before the system begins to trip
over itself and stop being a pleasure to work with. In fact, it's a slap in the
face. You develop this intricate and beautiful system (speaking collectively and
generally, of course) and it begins to feel tainted. In order to prevent it from
developing into a ball of mud - a truly unmaintainable mess - the act of
refactoring is inevitable, especially if we want to ensure that the project
survives and is actively developed for any length of time.
In this case, the glaring problem is that each of the modules are terribly,
tightly coupled. This reduces the flexibility of the system and forces us to
resort to a system riddled with conditionals. This becomes increasingly apparent
when we need to provide slightly different implementations between environments
(e.g. ES5/pre-ES5, production/development, etc and every combination).
Therefore, we need to decouple the modules in order to take advantage of
composition in order to provide more flexible feature sets depending on
environment.
What does this mean?
We need to move from object literals for the modules to prototypes (class-like,
but remember that ease.js exists because JS does not have "classes"). A number
of other prototypes can be extracted from the existing modules and abstracted to
the point where they can be appropriately injected where necessary. Rather than
using conditions for features such as fallbacks, we can encapsulate the entire
system in a facade that contains the features relevant to that particular
environment. This will also have the consequence that we can once again test
individual units rather than systems.
At the point of this commit (this entry was written before any work was done),
the major hurdle is refactoring the test cases so that they do not depend on
fallback logic and instead simply test specific units and skip the test if the
unit (the prototype) is not supported by the environment (e.g. proxies in a
pre-ES5 environment). This will allow us to finish refactoring the fallback and
environment-specific logic. It will also allow us to cleanly specify a fallback
implementation (through composition) in an ES5 environment while keeping ES5
detection mechanisms separate.
The remaining refactorings will likely be progressive. This all stemmed out of
the desire to add the method hiding feature, whose implementation varies
depending on environment. I want to get back to developing that feature so I can
get the first release (v0.1.0) out. Refactoring can continue after that point.
This project needs a version number so it can be used reliably.
2011-10-10 23:25:23 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-11-03 21:23:40 -04:00
|
|
|
// only output statistics if we're not running a suite (otherwise they'll be
|
|
|
|
// output at the end of the suite)
|
|
|
|
if ( !( suite ) )
|
|
|
|
{
|
|
|
|
endStats();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
|
2011-11-19 14:09:23 -05:00
|
|
|
/**
|
|
|
|
* Attempt a test
|
|
|
|
*
|
2012-05-03 21:46:33 -04:00
|
|
|
* @param {Object} test_case object containing all test cases
|
|
|
|
* @param {string} test complete key of test to run
|
|
|
|
* @param {Function} setUp test setup method, or null
|
|
|
|
* @param {string} test_str text to use on failure
|
|
|
|
* @param {Object} context context to bind to test function
|
|
|
|
* @param {Array} args arguments to pass to test function
|
2011-11-19 14:09:23 -05:00
|
|
|
*
|
|
|
|
* @return {undefined}
|
|
|
|
*/
|
2012-05-03 21:46:33 -04:00
|
|
|
function tryTest( test_case, test, setUp, test_str, context, args )
|
2011-11-19 14:09:23 -05:00
|
|
|
{
|
|
|
|
var acount_last = acount;
|
|
|
|
|
|
|
|
try
|
|
|
|
{
|
2012-05-03 21:46:33 -04:00
|
|
|
// xUnit-style setup
|
|
|
|
if ( setUp )
|
|
|
|
{
|
|
|
|
setUp.call( context );
|
|
|
|
}
|
|
|
|
|
2011-11-19 14:09:23 -05:00
|
|
|
test_case[ test ].apply( context, args );
|
|
|
|
|
|
|
|
// if there were no assertions, then the test should be marked as
|
|
|
|
// incomplete
|
|
|
|
if ( acount_last === acount )
|
|
|
|
{
|
|
|
|
testPrint( 'I' );
|
|
|
|
icount++;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
scount++;
|
|
|
|
testPrint( '.' );
|
|
|
|
}
|
|
|
|
}
|
|
|
|
catch ( e )
|
|
|
|
{
|
|
|
|
if ( e === SkipTest )
|
|
|
|
{
|
|
|
|
testPrint( 'S' );
|
|
|
|
skpcount++;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
testPrint( 'F' );
|
|
|
|
failures.push( [ test_str, e ] );
|
|
|
|
}
|
|
|
|
}
|
2011-11-19 14:15:31 -05:00
|
|
|
|
|
|
|
tcount++;
|
2011-11-19 14:09:23 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-11-03 21:23:40 -04:00
|
|
|
/**
|
|
|
|
* Reset counters
|
|
|
|
*/
|
|
|
|
function init()
|
|
|
|
{
|
|
|
|
failures = [];
|
2011-11-05 09:38:57 -04:00
|
|
|
scount = acount = icount = skpcount = 0;
|
2011-11-03 21:23:40 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Display end stats (failures, counts)
|
|
|
|
*/
|
|
|
|
function endStats()
|
|
|
|
{
|
Added very basic formatted output and failure tolerance for test case
The one year anniversary of the beginning of the ease.js project is quickly
approaching. I find myself to be not quite where I had expected many months ago,
but find that the project has evolved so much further than I had event
originally anticipated. My main motivation behind the project continues to be
making my life at work easier, while providing an excellent library that others
can hopefully benefit from. If anything, it's a fascinating experiment and
clever hack around JavaScript.
Now I find myself with a newborn child (nearly four weeks old), who demands my
constant attention (and indeed, it is difficult to find the desire to put my
attention elsewhere). Still - I am a hacker. Software is my passion. So the
project must move forward.
I also find myself unwilling to create a blog for ease.js. I feel it's
inappropriate for a project that's in its (relative) infancy and does not have
much popularity (it has never been announced to anyone). As such, I feel that
commit messages will serve my purpose as useful journal entries regarding the
status of the project. They will also be interesting easter eggs for those who
would wish to seek them out for additional perspective on the project. (Granted,
one could easy script the discovery of such entries by examining the absurd
length of the commit message...perhaps the git log manpages would be useful).
So. Let's get back to the project.
ease.js is currently going through a strong refactoring in order to address
design issues that have begun to creep up as the project grew. The initial
design was a very simple one - a "series of modules", as it was originally
described in a CommonJS sense, that would provide features of a classical
Object-Oriented system. It would seem ironic that, having a focus on
classical Object-Oriented development, one would avoid developing the project in
such a paradigm. Instead, I wished to keep the design simple (because the
project seemed simple), more natural to JS developers (prototypal) and
performant (object literals do not have the overhead of instantiation). Well,
unfortunately, the project scope has increased drastically due to the success of
the implementation (and my playfulness), the chosen paradigm has become awkward
in itself and the performance benefit is indeed a micro-optimization when
compared with the performance of both the rest of the system and the system that
will implement ease.js as a framework.
You can only put off refactoring for so long before the system begins to trip
over itself and stop being a pleasure to work with. In fact, it's a slap in the
face. You develop this intricate and beautiful system (speaking collectively and
generally, of course) and it begins to feel tainted. In order to prevent it from
developing into a ball of mud - a truly unmaintainable mess - the act of
refactoring is inevitable, especially if we want to ensure that the project
survives and is actively developed for any length of time.
In this case, the glaring problem is that each of the modules are terribly,
tightly coupled. This reduces the flexibility of the system and forces us to
resort to a system riddled with conditionals. This becomes increasingly apparent
when we need to provide slightly different implementations between environments
(e.g. ES5/pre-ES5, production/development, etc and every combination).
Therefore, we need to decouple the modules in order to take advantage of
composition in order to provide more flexible feature sets depending on
environment.
What does this mean?
We need to move from object literals for the modules to prototypes (class-like,
but remember that ease.js exists because JS does not have "classes"). A number
of other prototypes can be extracted from the existing modules and abstracted to
the point where they can be appropriately injected where necessary. Rather than
using conditions for features such as fallbacks, we can encapsulate the entire
system in a facade that contains the features relevant to that particular
environment. This will also have the consequence that we can once again test
individual units rather than systems.
At the point of this commit (this entry was written before any work was done),
the major hurdle is refactoring the test cases so that they do not depend on
fallback logic and instead simply test specific units and skip the test if the
unit (the prototype) is not supported by the environment (e.g. proxies in a
pre-ES5 environment). This will allow us to finish refactoring the fallback and
environment-specific logic. It will also allow us to cleanly specify a fallback
implementation (through composition) in an ES5 environment while keeping ES5
detection mechanisms separate.
The remaining refactorings will likely be progressive. This all stemmed out of
the desire to add the method hiding feature, whose implementation varies
depending on environment. I want to get back to developing that feature so I can
get the first release (v0.1.0) out. Refactoring can continue after that point.
This project needs a version number so it can be used reliably.
2011-10-10 23:25:23 -04:00
|
|
|
testPrint( "\n\n" );
|
|
|
|
|
|
|
|
if ( failures.length )
|
|
|
|
{
|
|
|
|
outputTestFailures( failures );
|
|
|
|
}
|
|
|
|
|
|
|
|
// print test case summary
|
|
|
|
testPrint(
|
|
|
|
( ( failures.length ) ? "FAILED" : "OK" ) + " - " +
|
|
|
|
scount + " successful, " + failures.length + " failure(s), " +
|
2011-11-03 22:25:00 -04:00
|
|
|
( ( icount > 0 ) ? icount + ' incomplete, ' : '' ) +
|
2011-11-05 09:38:57 -04:00
|
|
|
( ( skpcount > 0 ) ? skpcount + ' skipped, ' : '' ) +
|
|
|
|
( scount + icount + skpcount + failures.length ) + " total " +
|
2011-10-21 10:23:56 -04:00
|
|
|
'(' + acount + " assertion" + ( ( acount !== 1 ) ? 's' : '' ) + ")\n"
|
Added very basic formatted output and failure tolerance for test case
The one year anniversary of the beginning of the ease.js project is quickly
approaching. I find myself to be not quite where I had expected many months ago,
but find that the project has evolved so much further than I had event
originally anticipated. My main motivation behind the project continues to be
making my life at work easier, while providing an excellent library that others
can hopefully benefit from. If anything, it's a fascinating experiment and
clever hack around JavaScript.
Now I find myself with a newborn child (nearly four weeks old), who demands my
constant attention (and indeed, it is difficult to find the desire to put my
attention elsewhere). Still - I am a hacker. Software is my passion. So the
project must move forward.
I also find myself unwilling to create a blog for ease.js. I feel it's
inappropriate for a project that's in its (relative) infancy and does not have
much popularity (it has never been announced to anyone). As such, I feel that
commit messages will serve my purpose as useful journal entries regarding the
status of the project. They will also be interesting easter eggs for those who
would wish to seek them out for additional perspective on the project. (Granted,
one could easy script the discovery of such entries by examining the absurd
length of the commit message...perhaps the git log manpages would be useful).
So. Let's get back to the project.
ease.js is currently going through a strong refactoring in order to address
design issues that have begun to creep up as the project grew. The initial
design was a very simple one - a "series of modules", as it was originally
described in a CommonJS sense, that would provide features of a classical
Object-Oriented system. It would seem ironic that, having a focus on
classical Object-Oriented development, one would avoid developing the project in
such a paradigm. Instead, I wished to keep the design simple (because the
project seemed simple), more natural to JS developers (prototypal) and
performant (object literals do not have the overhead of instantiation). Well,
unfortunately, the project scope has increased drastically due to the success of
the implementation (and my playfulness), the chosen paradigm has become awkward
in itself and the performance benefit is indeed a micro-optimization when
compared with the performance of both the rest of the system and the system that
will implement ease.js as a framework.
You can only put off refactoring for so long before the system begins to trip
over itself and stop being a pleasure to work with. In fact, it's a slap in the
face. You develop this intricate and beautiful system (speaking collectively and
generally, of course) and it begins to feel tainted. In order to prevent it from
developing into a ball of mud - a truly unmaintainable mess - the act of
refactoring is inevitable, especially if we want to ensure that the project
survives and is actively developed for any length of time.
In this case, the glaring problem is that each of the modules are terribly,
tightly coupled. This reduces the flexibility of the system and forces us to
resort to a system riddled with conditionals. This becomes increasingly apparent
when we need to provide slightly different implementations between environments
(e.g. ES5/pre-ES5, production/development, etc and every combination).
Therefore, we need to decouple the modules in order to take advantage of
composition in order to provide more flexible feature sets depending on
environment.
What does this mean?
We need to move from object literals for the modules to prototypes (class-like,
but remember that ease.js exists because JS does not have "classes"). A number
of other prototypes can be extracted from the existing modules and abstracted to
the point where they can be appropriately injected where necessary. Rather than
using conditions for features such as fallbacks, we can encapsulate the entire
system in a facade that contains the features relevant to that particular
environment. This will also have the consequence that we can once again test
individual units rather than systems.
At the point of this commit (this entry was written before any work was done),
the major hurdle is refactoring the test cases so that they do not depend on
fallback logic and instead simply test specific units and skip the test if the
unit (the prototype) is not supported by the environment (e.g. proxies in a
pre-ES5 environment). This will allow us to finish refactoring the fallback and
environment-specific logic. It will also allow us to cleanly specify a fallback
implementation (through composition) in an ES5 environment while keeping ES5
detection mechanisms separate.
The remaining refactorings will likely be progressive. This all stemmed out of
the desire to add the method hiding feature, whose implementation varies
depending on environment. I want to get back to developing that feature so I can
get the first release (v0.1.0) out. Refactoring can continue after that point.
This project needs a version number so it can be used reliably.
2011-10-10 23:25:23 -04:00
|
|
|
);
|
|
|
|
|
|
|
|
// exit with non-zero status to indicate failure
|
|
|
|
failures.length
|
|
|
|
&& typeof process !== 'undefined'
|
|
|
|
&& process.exit( 1 );
|
2011-11-03 21:23:40 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Start test suite, deferring summary stats until call to endSuite()
|
|
|
|
*/
|
|
|
|
module.exports.startSuite = function()
|
|
|
|
{
|
|
|
|
init();
|
|
|
|
suite = true;
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Ens test suite, display stats buffered since startSuite()
|
|
|
|
*/
|
|
|
|
module.exports.endSuite = function()
|
|
|
|
{
|
|
|
|
suite = false;
|
|
|
|
endStats();
|
Added very basic formatted output and failure tolerance for test case
The one year anniversary of the beginning of the ease.js project is quickly
approaching. I find myself to be not quite where I had expected many months ago,
but find that the project has evolved so much further than I had event
originally anticipated. My main motivation behind the project continues to be
making my life at work easier, while providing an excellent library that others
can hopefully benefit from. If anything, it's a fascinating experiment and
clever hack around JavaScript.
Now I find myself with a newborn child (nearly four weeks old), who demands my
constant attention (and indeed, it is difficult to find the desire to put my
attention elsewhere). Still - I am a hacker. Software is my passion. So the
project must move forward.
I also find myself unwilling to create a blog for ease.js. I feel it's
inappropriate for a project that's in its (relative) infancy and does not have
much popularity (it has never been announced to anyone). As such, I feel that
commit messages will serve my purpose as useful journal entries regarding the
status of the project. They will also be interesting easter eggs for those who
would wish to seek them out for additional perspective on the project. (Granted,
one could easy script the discovery of such entries by examining the absurd
length of the commit message...perhaps the git log manpages would be useful).
So. Let's get back to the project.
ease.js is currently going through a strong refactoring in order to address
design issues that have begun to creep up as the project grew. The initial
design was a very simple one - a "series of modules", as it was originally
described in a CommonJS sense, that would provide features of a classical
Object-Oriented system. It would seem ironic that, having a focus on
classical Object-Oriented development, one would avoid developing the project in
such a paradigm. Instead, I wished to keep the design simple (because the
project seemed simple), more natural to JS developers (prototypal) and
performant (object literals do not have the overhead of instantiation). Well,
unfortunately, the project scope has increased drastically due to the success of
the implementation (and my playfulness), the chosen paradigm has become awkward
in itself and the performance benefit is indeed a micro-optimization when
compared with the performance of both the rest of the system and the system that
will implement ease.js as a framework.
You can only put off refactoring for so long before the system begins to trip
over itself and stop being a pleasure to work with. In fact, it's a slap in the
face. You develop this intricate and beautiful system (speaking collectively and
generally, of course) and it begins to feel tainted. In order to prevent it from
developing into a ball of mud - a truly unmaintainable mess - the act of
refactoring is inevitable, especially if we want to ensure that the project
survives and is actively developed for any length of time.
In this case, the glaring problem is that each of the modules are terribly,
tightly coupled. This reduces the flexibility of the system and forces us to
resort to a system riddled with conditionals. This becomes increasingly apparent
when we need to provide slightly different implementations between environments
(e.g. ES5/pre-ES5, production/development, etc and every combination).
Therefore, we need to decouple the modules in order to take advantage of
composition in order to provide more flexible feature sets depending on
environment.
What does this mean?
We need to move from object literals for the modules to prototypes (class-like,
but remember that ease.js exists because JS does not have "classes"). A number
of other prototypes can be extracted from the existing modules and abstracted to
the point where they can be appropriately injected where necessary. Rather than
using conditions for features such as fallbacks, we can encapsulate the entire
system in a facade that contains the features relevant to that particular
environment. This will also have the consequence that we can once again test
individual units rather than systems.
At the point of this commit (this entry was written before any work was done),
the major hurdle is refactoring the test cases so that they do not depend on
fallback logic and instead simply test specific units and skip the test if the
unit (the prototype) is not supported by the environment (e.g. proxies in a
pre-ES5 environment). This will allow us to finish refactoring the fallback and
environment-specific logic. It will also allow us to cleanly specify a fallback
implementation (through composition) in an ES5 environment while keeping ES5
detection mechanisms separate.
The remaining refactorings will likely be progressive. This all stemmed out of
the desire to add the method hiding feature, whose implementation varies
depending on environment. I want to get back to developing that feature so I can
get the first release (v0.1.0) out. Refactoring can continue after that point.
This project needs a version number so it can be used reliably.
2011-10-10 23:25:23 -04:00
|
|
|
};
|
|
|
|
|
|
|
|
|
2011-11-02 23:28:23 -04:00
|
|
|
function getMock( proto )
|
|
|
|
{
|
|
|
|
var P = common_require( proto ),
|
|
|
|
Mock = function() {},
|
|
|
|
|
|
|
|
proto = Mock.prototype = new P()
|
|
|
|
;
|
|
|
|
|
2011-12-10 11:06:34 -05:00
|
|
|
for ( var i in proto )
|
2011-11-02 23:28:23 -04:00
|
|
|
{
|
|
|
|
// only mock out methods
|
|
|
|
if ( typeof proto[ i ] !== 'function' )
|
|
|
|
{
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// clear the method
|
|
|
|
proto[ i ] = function() {};
|
|
|
|
}
|
|
|
|
|
|
|
|
return new Mock();
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-11-05 09:38:57 -04:00
|
|
|
function skipTest()
|
|
|
|
{
|
|
|
|
throw SkipTest;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
Added very basic formatted output and failure tolerance for test case
The one year anniversary of the beginning of the ease.js project is quickly
approaching. I find myself to be not quite where I had expected many months ago,
but find that the project has evolved so much further than I had event
originally anticipated. My main motivation behind the project continues to be
making my life at work easier, while providing an excellent library that others
can hopefully benefit from. If anything, it's a fascinating experiment and
clever hack around JavaScript.
Now I find myself with a newborn child (nearly four weeks old), who demands my
constant attention (and indeed, it is difficult to find the desire to put my
attention elsewhere). Still - I am a hacker. Software is my passion. So the
project must move forward.
I also find myself unwilling to create a blog for ease.js. I feel it's
inappropriate for a project that's in its (relative) infancy and does not have
much popularity (it has never been announced to anyone). As such, I feel that
commit messages will serve my purpose as useful journal entries regarding the
status of the project. They will also be interesting easter eggs for those who
would wish to seek them out for additional perspective on the project. (Granted,
one could easy script the discovery of such entries by examining the absurd
length of the commit message...perhaps the git log manpages would be useful).
So. Let's get back to the project.
ease.js is currently going through a strong refactoring in order to address
design issues that have begun to creep up as the project grew. The initial
design was a very simple one - a "series of modules", as it was originally
described in a CommonJS sense, that would provide features of a classical
Object-Oriented system. It would seem ironic that, having a focus on
classical Object-Oriented development, one would avoid developing the project in
such a paradigm. Instead, I wished to keep the design simple (because the
project seemed simple), more natural to JS developers (prototypal) and
performant (object literals do not have the overhead of instantiation). Well,
unfortunately, the project scope has increased drastically due to the success of
the implementation (and my playfulness), the chosen paradigm has become awkward
in itself and the performance benefit is indeed a micro-optimization when
compared with the performance of both the rest of the system and the system that
will implement ease.js as a framework.
You can only put off refactoring for so long before the system begins to trip
over itself and stop being a pleasure to work with. In fact, it's a slap in the
face. You develop this intricate and beautiful system (speaking collectively and
generally, of course) and it begins to feel tainted. In order to prevent it from
developing into a ball of mud - a truly unmaintainable mess - the act of
refactoring is inevitable, especially if we want to ensure that the project
survives and is actively developed for any length of time.
In this case, the glaring problem is that each of the modules are terribly,
tightly coupled. This reduces the flexibility of the system and forces us to
resort to a system riddled with conditionals. This becomes increasingly apparent
when we need to provide slightly different implementations between environments
(e.g. ES5/pre-ES5, production/development, etc and every combination).
Therefore, we need to decouple the modules in order to take advantage of
composition in order to provide more flexible feature sets depending on
environment.
What does this mean?
We need to move from object literals for the modules to prototypes (class-like,
but remember that ease.js exists because JS does not have "classes"). A number
of other prototypes can be extracted from the existing modules and abstracted to
the point where they can be appropriately injected where necessary. Rather than
using conditions for features such as fallbacks, we can encapsulate the entire
system in a facade that contains the features relevant to that particular
environment. This will also have the consequence that we can once again test
individual units rather than systems.
At the point of this commit (this entry was written before any work was done),
the major hurdle is refactoring the test cases so that they do not depend on
fallback logic and instead simply test specific units and skip the test if the
unit (the prototype) is not supported by the environment (e.g. proxies in a
pre-ES5 environment). This will allow us to finish refactoring the fallback and
environment-specific logic. It will also allow us to cleanly specify a fallback
implementation (through composition) in an ES5 environment while keeping ES5
detection mechanisms separate.
The remaining refactorings will likely be progressive. This all stemmed out of
the desire to add the method hiding feature, whose implementation varies
depending on environment. I want to get back to developing that feature so I can
get the first release (v0.1.0) out. Refactoring can continue after that point.
This project needs a version number so it can be used reliably.
2011-10-10 23:25:23 -04:00
|
|
|
/**
|
|
|
|
* Prepare assertion methods on context
|
|
|
|
*
|
|
|
|
* @return {Object} context
|
|
|
|
*/
|
|
|
|
function prepareCaseContext()
|
|
|
|
{
|
|
|
|
return {
|
2011-11-02 23:28:23 -04:00
|
|
|
require: common_require,
|
Added very basic formatted output and failure tolerance for test case
The one year anniversary of the beginning of the ease.js project is quickly
approaching. I find myself to be not quite where I had expected many months ago,
but find that the project has evolved so much further than I had event
originally anticipated. My main motivation behind the project continues to be
making my life at work easier, while providing an excellent library that others
can hopefully benefit from. If anything, it's a fascinating experiment and
clever hack around JavaScript.
Now I find myself with a newborn child (nearly four weeks old), who demands my
constant attention (and indeed, it is difficult to find the desire to put my
attention elsewhere). Still - I am a hacker. Software is my passion. So the
project must move forward.
I also find myself unwilling to create a blog for ease.js. I feel it's
inappropriate for a project that's in its (relative) infancy and does not have
much popularity (it has never been announced to anyone). As such, I feel that
commit messages will serve my purpose as useful journal entries regarding the
status of the project. They will also be interesting easter eggs for those who
would wish to seek them out for additional perspective on the project. (Granted,
one could easy script the discovery of such entries by examining the absurd
length of the commit message...perhaps the git log manpages would be useful).
So. Let's get back to the project.
ease.js is currently going through a strong refactoring in order to address
design issues that have begun to creep up as the project grew. The initial
design was a very simple one - a "series of modules", as it was originally
described in a CommonJS sense, that would provide features of a classical
Object-Oriented system. It would seem ironic that, having a focus on
classical Object-Oriented development, one would avoid developing the project in
such a paradigm. Instead, I wished to keep the design simple (because the
project seemed simple), more natural to JS developers (prototypal) and
performant (object literals do not have the overhead of instantiation). Well,
unfortunately, the project scope has increased drastically due to the success of
the implementation (and my playfulness), the chosen paradigm has become awkward
in itself and the performance benefit is indeed a micro-optimization when
compared with the performance of both the rest of the system and the system that
will implement ease.js as a framework.
You can only put off refactoring for so long before the system begins to trip
over itself and stop being a pleasure to work with. In fact, it's a slap in the
face. You develop this intricate and beautiful system (speaking collectively and
generally, of course) and it begins to feel tainted. In order to prevent it from
developing into a ball of mud - a truly unmaintainable mess - the act of
refactoring is inevitable, especially if we want to ensure that the project
survives and is actively developed for any length of time.
In this case, the glaring problem is that each of the modules are terribly,
tightly coupled. This reduces the flexibility of the system and forces us to
resort to a system riddled with conditionals. This becomes increasingly apparent
when we need to provide slightly different implementations between environments
(e.g. ES5/pre-ES5, production/development, etc and every combination).
Therefore, we need to decouple the modules in order to take advantage of
composition in order to provide more flexible feature sets depending on
environment.
What does this mean?
We need to move from object literals for the modules to prototypes (class-like,
but remember that ease.js exists because JS does not have "classes"). A number
of other prototypes can be extracted from the existing modules and abstracted to
the point where they can be appropriately injected where necessary. Rather than
using conditions for features such as fallbacks, we can encapsulate the entire
system in a facade that contains the features relevant to that particular
environment. This will also have the consequence that we can once again test
individual units rather than systems.
At the point of this commit (this entry was written before any work was done),
the major hurdle is refactoring the test cases so that they do not depend on
fallback logic and instead simply test specific units and skip the test if the
unit (the prototype) is not supported by the environment (e.g. proxies in a
pre-ES5 environment). This will allow us to finish refactoring the fallback and
environment-specific logic. It will also allow us to cleanly specify a fallback
implementation (through composition) in an ES5 environment while keeping ES5
detection mechanisms separate.
The remaining refactorings will likely be progressive. This all stemmed out of
the desire to add the method hiding feature, whose implementation varies
depending on environment. I want to get back to developing that feature so I can
get the first release (v0.1.0) out. Refactoring can continue after that point.
This project needs a version number so it can be used reliably.
2011-10-10 23:25:23 -04:00
|
|
|
|
2011-10-21 10:23:56 -04:00
|
|
|
fail: assert_wrapped.fail,
|
|
|
|
assertOk: assert_wrapped.ok,
|
|
|
|
assertEqual: assert_wrapped.equal,
|
|
|
|
assertNotEqual: assert_wrapped.notEqual,
|
|
|
|
assertDeepEqual: assert_wrapped.deepEqual,
|
|
|
|
assertStrictEqual: assert_wrapped.strictEqual,
|
|
|
|
assertNotStrictEqual: assert_wrapped.notStrictEqual,
|
2011-12-04 19:26:53 -05:00
|
|
|
assertThrows: assert_wrapped['throws'],
|
2011-10-21 10:23:56 -04:00
|
|
|
assertDoesNotThrow: assert_wrapped.doesNotThrow,
|
|
|
|
assertIfError: assert_wrapped.ifError,
|
2011-10-21 10:27:37 -04:00
|
|
|
incAssertCount: incAssertCount,
|
2011-11-02 23:28:23 -04:00
|
|
|
|
|
|
|
getMock: getMock,
|
2011-11-05 09:38:57 -04:00
|
|
|
skip: skipTest,
|
Added very basic formatted output and failure tolerance for test case
The one year anniversary of the beginning of the ease.js project is quickly
approaching. I find myself to be not quite where I had expected many months ago,
but find that the project has evolved so much further than I had event
originally anticipated. My main motivation behind the project continues to be
making my life at work easier, while providing an excellent library that others
can hopefully benefit from. If anything, it's a fascinating experiment and
clever hack around JavaScript.
Now I find myself with a newborn child (nearly four weeks old), who demands my
constant attention (and indeed, it is difficult to find the desire to put my
attention elsewhere). Still - I am a hacker. Software is my passion. So the
project must move forward.
I also find myself unwilling to create a blog for ease.js. I feel it's
inappropriate for a project that's in its (relative) infancy and does not have
much popularity (it has never been announced to anyone). As such, I feel that
commit messages will serve my purpose as useful journal entries regarding the
status of the project. They will also be interesting easter eggs for those who
would wish to seek them out for additional perspective on the project. (Granted,
one could easy script the discovery of such entries by examining the absurd
length of the commit message...perhaps the git log manpages would be useful).
So. Let's get back to the project.
ease.js is currently going through a strong refactoring in order to address
design issues that have begun to creep up as the project grew. The initial
design was a very simple one - a "series of modules", as it was originally
described in a CommonJS sense, that would provide features of a classical
Object-Oriented system. It would seem ironic that, having a focus on
classical Object-Oriented development, one would avoid developing the project in
such a paradigm. Instead, I wished to keep the design simple (because the
project seemed simple), more natural to JS developers (prototypal) and
performant (object literals do not have the overhead of instantiation). Well,
unfortunately, the project scope has increased drastically due to the success of
the implementation (and my playfulness), the chosen paradigm has become awkward
in itself and the performance benefit is indeed a micro-optimization when
compared with the performance of both the rest of the system and the system that
will implement ease.js as a framework.
You can only put off refactoring for so long before the system begins to trip
over itself and stop being a pleasure to work with. In fact, it's a slap in the
face. You develop this intricate and beautiful system (speaking collectively and
generally, of course) and it begins to feel tainted. In order to prevent it from
developing into a ball of mud - a truly unmaintainable mess - the act of
refactoring is inevitable, especially if we want to ensure that the project
survives and is actively developed for any length of time.
In this case, the glaring problem is that each of the modules are terribly,
tightly coupled. This reduces the flexibility of the system and forces us to
resort to a system riddled with conditionals. This becomes increasingly apparent
when we need to provide slightly different implementations between environments
(e.g. ES5/pre-ES5, production/development, etc and every combination).
Therefore, we need to decouple the modules in order to take advantage of
composition in order to provide more flexible feature sets depending on
environment.
What does this mean?
We need to move from object literals for the modules to prototypes (class-like,
but remember that ease.js exists because JS does not have "classes"). A number
of other prototypes can be extracted from the existing modules and abstracted to
the point where they can be appropriately injected where necessary. Rather than
using conditions for features such as fallbacks, we can encapsulate the entire
system in a facade that contains the features relevant to that particular
environment. This will also have the consequence that we can once again test
individual units rather than systems.
At the point of this commit (this entry was written before any work was done),
the major hurdle is refactoring the test cases so that they do not depend on
fallback logic and instead simply test specific units and skip the test if the
unit (the prototype) is not supported by the environment (e.g. proxies in a
pre-ES5 environment). This will allow us to finish refactoring the fallback and
environment-specific logic. It will also allow us to cleanly specify a fallback
implementation (through composition) in an ES5 environment while keeping ES5
detection mechanisms separate.
The remaining refactorings will likely be progressive. This all stemmed out of
the desire to add the method hiding feature, whose implementation varies
depending on environment. I want to get back to developing that feature so I can
get the first release (v0.1.0) out. Refactoring can continue after that point.
This project needs a version number so it can be used reliably.
2011-10-10 23:25:23 -04:00
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Outputs test failures and their stack traces
|
|
|
|
*
|
|
|
|
* @param {Array} failures
|
|
|
|
*
|
|
|
|
* @return {undefined}
|
|
|
|
*/
|
|
|
|
function outputTestFailures( failures )
|
|
|
|
{
|
|
|
|
var i, cur, name, e;
|
|
|
|
|
2011-10-21 15:48:01 -04:00
|
|
|
// if we don't have stdout access, throw an error containing each of the
|
|
|
|
// error strings
|
|
|
|
if ( typeof process === 'undefined' )
|
|
|
|
{
|
|
|
|
var err = '',
|
|
|
|
i = failures.length;
|
|
|
|
|
2011-12-10 11:06:34 -05:00
|
|
|
for ( var i in failures )
|
2011-10-21 15:48:01 -04:00
|
|
|
{
|
2011-12-03 13:08:18 -05:00
|
|
|
var failure = failures[ i ];
|
|
|
|
|
|
|
|
err += failure[ 0 ] +
|
|
|
|
' (' + ( failure[ 1 ].message || 'no message' ) + ')' +
|
|
|
|
( ( failure[ 1 ].stack )
|
|
|
|
? ( '<br />' +
|
|
|
|
failure[ 1 ].stack.replace( /\n/g, '<br />' ) +
|
|
|
|
'<br />'
|
|
|
|
)
|
|
|
|
: '; '
|
|
|
|
)
|
2011-10-21 15:48:01 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
throw Error( err );
|
|
|
|
}
|
|
|
|
|
2011-12-10 11:06:34 -05:00
|
|
|
for ( var i = 0; i < failures.length; i++ )
|
Added very basic formatted output and failure tolerance for test case
The one year anniversary of the beginning of the ease.js project is quickly
approaching. I find myself to be not quite where I had expected many months ago,
but find that the project has evolved so much further than I had event
originally anticipated. My main motivation behind the project continues to be
making my life at work easier, while providing an excellent library that others
can hopefully benefit from. If anything, it's a fascinating experiment and
clever hack around JavaScript.
Now I find myself with a newborn child (nearly four weeks old), who demands my
constant attention (and indeed, it is difficult to find the desire to put my
attention elsewhere). Still - I am a hacker. Software is my passion. So the
project must move forward.
I also find myself unwilling to create a blog for ease.js. I feel it's
inappropriate for a project that's in its (relative) infancy and does not have
much popularity (it has never been announced to anyone). As such, I feel that
commit messages will serve my purpose as useful journal entries regarding the
status of the project. They will also be interesting easter eggs for those who
would wish to seek them out for additional perspective on the project. (Granted,
one could easy script the discovery of such entries by examining the absurd
length of the commit message...perhaps the git log manpages would be useful).
So. Let's get back to the project.
ease.js is currently going through a strong refactoring in order to address
design issues that have begun to creep up as the project grew. The initial
design was a very simple one - a "series of modules", as it was originally
described in a CommonJS sense, that would provide features of a classical
Object-Oriented system. It would seem ironic that, having a focus on
classical Object-Oriented development, one would avoid developing the project in
such a paradigm. Instead, I wished to keep the design simple (because the
project seemed simple), more natural to JS developers (prototypal) and
performant (object literals do not have the overhead of instantiation). Well,
unfortunately, the project scope has increased drastically due to the success of
the implementation (and my playfulness), the chosen paradigm has become awkward
in itself and the performance benefit is indeed a micro-optimization when
compared with the performance of both the rest of the system and the system that
will implement ease.js as a framework.
You can only put off refactoring for so long before the system begins to trip
over itself and stop being a pleasure to work with. In fact, it's a slap in the
face. You develop this intricate and beautiful system (speaking collectively and
generally, of course) and it begins to feel tainted. In order to prevent it from
developing into a ball of mud - a truly unmaintainable mess - the act of
refactoring is inevitable, especially if we want to ensure that the project
survives and is actively developed for any length of time.
In this case, the glaring problem is that each of the modules are terribly,
tightly coupled. This reduces the flexibility of the system and forces us to
resort to a system riddled with conditionals. This becomes increasingly apparent
when we need to provide slightly different implementations between environments
(e.g. ES5/pre-ES5, production/development, etc and every combination).
Therefore, we need to decouple the modules in order to take advantage of
composition in order to provide more flexible feature sets depending on
environment.
What does this mean?
We need to move from object literals for the modules to prototypes (class-like,
but remember that ease.js exists because JS does not have "classes"). A number
of other prototypes can be extracted from the existing modules and abstracted to
the point where they can be appropriately injected where necessary. Rather than
using conditions for features such as fallbacks, we can encapsulate the entire
system in a facade that contains the features relevant to that particular
environment. This will also have the consequence that we can once again test
individual units rather than systems.
At the point of this commit (this entry was written before any work was done),
the major hurdle is refactoring the test cases so that they do not depend on
fallback logic and instead simply test specific units and skip the test if the
unit (the prototype) is not supported by the environment (e.g. proxies in a
pre-ES5 environment). This will allow us to finish refactoring the fallback and
environment-specific logic. It will also allow us to cleanly specify a fallback
implementation (through composition) in an ES5 environment while keeping ES5
detection mechanisms separate.
The remaining refactorings will likely be progressive. This all stemmed out of
the desire to add the method hiding feature, whose implementation varies
depending on environment. I want to get back to developing that feature so I can
get the first release (v0.1.0) out. Refactoring can continue after that point.
This project needs a version number so it can be used reliably.
2011-10-10 23:25:23 -04:00
|
|
|
{
|
|
|
|
cur = failures[ i ];
|
|
|
|
|
|
|
|
name = cur[ 0 ];
|
|
|
|
e = cur[ 1 ];
|
|
|
|
|
|
|
|
// output the name followed by the stack trace
|
|
|
|
testPrint(
|
|
|
|
'#' + i + ' ' + name + '\n'
|
|
|
|
+ e.stack + "\n\n"
|
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Outputs a string if stdout is available (node.js)
|
|
|
|
*
|
|
|
|
* @param {string} str string to output
|
|
|
|
*
|
|
|
|
* @return {undefined}
|
|
|
|
*/
|
|
|
|
var testPrint = ( ( typeof process === 'undefined' )
|
|
|
|
|| ( typeof process.stdout === 'undefined' ) )
|
|
|
|
? function() {}
|
|
|
|
: function( str )
|
|
|
|
{
|
|
|
|
process.stdout.write( str );
|
|
|
|
};
|
|
|
|
|