Lake of unit tests

[GoogleCodeExporter]

0.1.2 broke a few thing that was working fine in 0.1.1. A good unit test
coverage would have eliminated the regression problem.

BTW, is this project still being worked on?

Original issue reported on code.google.com by kenne...@gmail.com on 31 Oct 2009 at 4:58

[GoogleCodeExporter]

Sorry I meant lack instead of lake. Google code doesn't let me edit now.

Original comment by kenne...@gmail.com on 31 Oct 2009 at 4:59

[GoogleCodeExporter]

True, and highly unfortunate :) I wrote most of the original code in a frenzy 
over 
two or three days, and I really didn't have time to document or write unit 
tests, 
though it's only a very poor excuse. And writing unit tests after the code has 
been 
written is much harder than the proper way around.

However, the 'Examples' serve as a kind of test suite, it just failed to catch 
the 
interface implementation problem because the only implicit interface 
implementation 
in all the examples is for GetEnumerator() - without parameters, and only 
explicit 
implementations are ever done with parameters.

As for working on the project - I'm mostly doing it as time permits (which came 
roughly to zero recently). Also, there has been minimal feedback over the 
years, 
except for the initial burst back on codeproject, so I wasn't sure if it makes 
sense 
to continue working on it. Now that I see that there are real people using it, 
it's 
more likely that I'll be trying to find the time to work on it.

Oh and for the really late reply - I forgot to activate notifications regarding 
issues on this project, so I wasn't really aware of them until today, when I 
opened 
the issue list just by a chance ;)

Original comment by StefanSi...@gmail.com on 22 Dec 2009 at 11:33

• Changed state: Accepted

[GoogleCodeExporter]

Hi,

Thanks for getting back to me. There is no doubt that this is a great idea and 
a nice
piece of work.

I found this project when I had a need to do some code generation and was 
looking for
a higher level API then Reflection.Emit, which I know it will become maintenance
nightmare.

I started with 0.1.1 in sourceforge and later found that there is 0.1.2 here in
google code. But eventually I gave up due to the issues that I have reported 
and some
features missing or incomplete. Initially I though I will take the code and 
enhance
it myself but that didn't work either because of low test coverage. I'm pretty 
sure
I'll break tons of things without knowing them if I dare to proceed. :)

So I decide to go ahead and do something different myself after two weeks of 
waiting.
My goal was a little different then RunSharp.

 1. Multi-threading support is essential.
 2. Generate members based on existing MemberInfo, MethodInfo and PropertyInfo is top
important. As mostly liking, code generation will be implementing some existing 
API
or overriding some class and etc.
 3. Fluent API is not the goal as I assume the API will be used by advanced
developers who reads the API doc.
 4. Syntax should more focus on ease of use pragmatically instead of mimicking C#.
 5. Ideally, I can just use one syntax for Reflection.Emit and CodeDom.

So I started with something pure interface based and only implements what I 
need as I
go. So my code coverage was decent. I have actually completed to the point that 
I can
implement a dynamic proxy to enable INotifyPropertyChanged on a value object 
that has
an interface. My NotifyPropertyChangeFactory is quite maintainable as it has 
almost
no Reflection.Emit code.

But the more I go, the more I realized the limitation of pure interface 
approach,
mainly due to C# doesn't support implicit conversion for interface type. Also to
support a half baked type and concrete type. I know TypeBuilder implements Type 
but
what about CodeDom?

I have no documentation but if you are interested, the code is
http://code.google.com/p/kennethxublogsource/source/browse/trunk/Sandbox/src/Cod
eSharp/
and
http://code.google.com/p/kennethxublogsource/source/browse/trunk/Sandbox/test/Co
deSharp.Tests/

So I don't if this is a bad news or good news, but I'm no longer demanding any 
of
those bugs to be fixed.

Cheers,
Kenneth

Original comment by kenne...@gmail.com on 22 Dec 2009 at 8:11