1
0
Fork 0
Commit Graph

964 Commits (dd7b06247459017850672f8a992a66b4c6b2a58f)

Author SHA1 Message Date
Mike Gerwitz 31a7980e37 [#25] Moved bulk of visibility escalation test into common file to be shared with other member tests 2011-10-28 20:22:14 -04:00
Mike Gerwitz 93021f3dbc [#25] Moved getter/setter validation tests into new test case
Much more elegant a test case now.
2011-10-28 00:22:50 -04:00
Mike Gerwitz ad0343fb9b [#25] Moved getter/setter validation logic into MemberBuilderValidator
- Tests have not yet been moved
2011-10-28 00:08:22 -04:00
Mike Gerwitz 05df0b485c [#25] Moved single access modifier getter/setter test to VisibilityTest 2011-10-27 20:46:30 -04:00
Mike Gerwitz f19a62e733 [#25] Moved public default getter/setter test to new location 2011-10-27 20:43:56 -04:00
Mike Gerwitz a959e99b06 [#25] Removed replaced vis tests from test-emmber_builder-gettersetter 2011-10-27 19:53:43 -04:00
Mike Gerwitz 5959956a27 [#25] this => _self replacements in MemberBuilder/VisibilityTest 2011-10-27 19:52:43 -04:00
Mike Gerwitz 11020a9d2a [#25] Minor typo fix in MemberBuilder/VisibilityTest 2011-10-27 19:51:28 -04:00
Mike Gerwitz 1ba160e51c [#25] Added getter/setter vis test to MemberBuilder/VisibilityTest 2011-10-27 19:50:13 -04:00
Mike Gerwitz ce7853965e [#25] Combined separate property and method vis test 2011-10-27 19:28:36 -04:00
Mike Gerwitz 6d1cc06c27 [#25] Finished refactoring MemberBuilder/MethodTest and removed inc-member_builder-common (no longer needed)
Finally feels like things are starting to come together.

It's rather interesting looking back. Each time I begin writing a piece of
software, I think to myself, "This is the best way to do it." Well, generally.
Perhaps the implementation could have been better, but I may not have had the
time. However, the general concept remains.

Each time I look back months later and find that I disagree with certain
decisions. I find certain implementations to be messy or poorly constructed. Or
perhaps I was just being lazy to begin with. Whatever the case, it is
comforting. It shows that one is continuing to learn and evolve.

Now, in the case of ease.js, we're working with a number of different factors in
regards to my perception of prior code quality. Primarily, I'm looking at a
basic implementation (in this case, I'm referring to test cases) that served as
a foundation that could be later evolved. I didn't have the time to devote to a
stronger solution. However, since the project has evolved so far past my
original expectations, a more sophisticated solution is needed in order to
simplify the overall design. That is what happened here.

Of course, we're also looking at a year's worth of additional, intimate
experience with a language.

Regardless of the reason, I love to see software evolve. Especially my own. It's
as if I'm watching my child grow. From that, I can get a great deal of
satisfaction.

One shouldn't expect perfection. But one should certainly aim for it.
2011-10-26 23:39:03 -04:00
Mike Gerwitz 88cff48599 [#25] Moved remaining tests in test-member_builder into MemberBuilder/VisibilityTest 2011-10-26 22:12:28 -04:00
Mike Gerwitz 2d494d577e [#25] Removed test-member_builder-prop; all tests have been moved 2011-10-26 00:03:26 -04:00
Mike Gerwitz e90699c805 [#25] Added test to MemberBuilder/Visibility test to ensure members will be declared public by default (if no access modifier is given) 2011-10-25 23:47:06 -04:00
Mike Gerwitz f4b8eb3589 [#25] Added test in MemberBuilder/VisibilityTest to ensure multiple access modifiers are not used 2011-10-25 23:30:57 -04:00
Mike Gerwitz 3482eb4cd7 [#25] Removed method hiding test (can restore when reimplementing) 2011-10-25 22:29:03 -04:00
Mike Gerwitz 625f62bbf1 [#25] Moved MemberBuilderValidator property tests into new test case 2011-10-23 01:14:13 -04:00
Mike Gerwitz 6fc3d05166 [#25] Moved quick keyword validation into shared MemberBuilderValidator test module 2011-10-23 01:11:09 -04:00
Mike Gerwitz a91cb01998 [#25] Moved MethodBuilder property validation into MemberBuilderValidator
- Tests have not yet been moved
2011-10-23 00:43:08 -04:00
Mike Gerwitz 5e46298e39 [#25] Moved MemberBuilderValidator's quickFailureTest into its own file to share with upcoming property tests 2011-10-23 00:27:25 -04:00
Mike Gerwitz 0d0372cb87 [#25] Adding proper dirname to combined tests 2011-10-23 00:22:43 -04:00
Mike Gerwitz 9b629b8b61 [#25] Removed tests from MemberBuilder/MethodTest that have been refactored into MemberBuilderValidator/MethodTest 2011-10-23 00:06:22 -04:00
Mike Gerwitz 9fe26e7582 [#25] Moved MemberBuilderValidator/MethodTest's helper functions into caseSetUp() 2011-10-22 16:49:51 -04:00
Mike Gerwitz 2da2247c86 [#25] Added successful test to MemberBuilderValidator's method tests to ensure successful functionality is also tested 2011-10-22 16:47:09 -04:00
Mike Gerwitz 8ebcc3f1b3 [#25] Removed duplicate code from MemberBuilderValidator method test 2011-10-22 16:37:58 -04:00
Mike Gerwitz cf99aa88e8 [#25] Added README.todo 2011-10-22 16:32:55 -04:00
Mike Gerwitz a5e2a507f2 [#25] Throwing error instead of method hiding; will implement in future 2011-10-22 13:57:17 -04:00
Mike Gerwitz 6e7e031ff9 [#25] [#25] Re-added accidently removed portion of test 2011-10-22 11:06:03 -04:00
Mike Gerwitz f9b951ddb2 [#25] [#25] Began moving MemberBuilder validation rules into MemberBuilderValidator (moved method rules) 2011-10-22 01:00:45 -04:00
Mike Gerwitz e6830b741f [#25] Now using keywords to compare visibility levels in validations to eliminiate fallback inconsistencies
Ironic, considering the current refactoring (not yet committed) of MemberBuilder to split validation logic into MemberBuilderValidator was partially to be able to easily override the fallback logic. It's a useful refactoring nonetheless, but it could have waited.
2011-10-22 00:32:59 -04:00
Mike Gerwitz f6369ba2c4 [#25] No longer using util.isAbstractMethod() for method validation 2011-10-22 00:13:51 -04:00
Mike Gerwitz 4d2d95a99f [#25] Added test case error output for browser 2011-10-21 16:04:27 -04:00
Mike Gerwitz aeff796332 [#25] [#25] Added member builder tests for private and protected members 2011-10-21 16:04:24 -04:00
Mike Gerwitz ea972bdffc [#25] Added ability to manually increment assertion count for custom assertions 2011-10-21 12:10:53 -04:00
Mike Gerwitz 9ea60a18b0 [#25] Added assertion count to testcase output 2011-10-21 12:10:53 -04:00
Mike Gerwitz f7700f93e5 [#25] Refactored MemberBuilder/VisibilityTest basic tests into reusable functions for upcoming tests in other access levels 2011-10-21 12:10:49 -04:00
Mike Gerwitz bb9eb16fd3 [#25] Began adding MemberBuilder/VisibilityTest to test MemberBuilder directly
As mentioned in a prior commit blog-like entry, many of the tests evolved into more of an integration or system-level type of test. Let's get away from that.
2011-10-21 12:09:00 -04:00
Mike Gerwitz 474d8f307d [#25] Added caseSetUp() for test cases 2011-10-21 10:57:34 -04:00
Mike Gerwitz c1207eb3d5 Moved MemberBuilder-MethodTest into MemberBuilder subdir
- Altered combine script to support subdirs (note that the dir names aren't included in the combined file)
2011-10-20 23:40:30 -04:00
Mike Gerwitz a36a69e1ff Makefile now recognizes all tests for rebuild 2011-10-20 22:58:47 -04:00
Mike Gerwitz 8c0058698a Removed accidental commit of console.log() in test-combine.js 2011-10-14 22:36:10 -04:00
Mike Gerwitz 9c9759a2b1 Moved validateMethod() function into MemberBuilder prototype to prepare for overriding with FallbackMemberBuilder 2011-10-14 22:14:29 -04:00
Mike Gerwitz c9b5fb32d0 Merge branch 'master' into virtual/refactor/master 2011-10-14 22:08:08 -04:00
Mike Gerwitz dd82e53c8f Merge branch 'master' into virtual/master 2011-10-14 22:08:03 -04:00
Mike Gerwitz 4403bc4639 Updated URL in combined license 2011-10-14 22:07:45 -04:00
Mike Gerwitz 024f3b778c Began adding FallbackMemberBuilder test case
This is the first test case to use the new basic xUnit-style system. This
system is likely to evolve over time. Right now it's purely for
setUp, organizational and output purposes.
2011-10-14 22:05:22 -04:00
Mike Gerwitz c10fc5818a 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-12 18:53:52 -04:00
Mike Gerwitz eb63fb812c Merge branch 'virtual/master' into virtual/refactor/master 2011-09-21 18:24:35 -04:00
Mike Gerwitz d45e0e9dc2 Removed new virtual/master reference from README that was added in master branch 2011-09-21 18:24:15 -04:00
Mike Gerwitz e6362b8d11 Merge branch 'master' into virtual/master 2011-09-21 12:03:14 -04:00