Open DinisCruz opened 9 years ago
I found another solution for this problem , hope it is ok . However ,I tried to implement the constructor of the attribute using AST and I ended up referencing other projects like FluentSharp.AST and SharpDevelop and I thought is not ok with the purpose of an Unit Test project.
Yes, let's try to keep the dependencies Unit Tests of the FluentSharp.CoreLib limited to be bare minimum
@alexandrustanimir the solution you found was quite cool, can you see the refactoring that I did to it?
Now you can call it like:
[Test]
[UnitTestMethodReference("create_Folder")]
public void createFolder()
{
MethodBase.GetCurrentMethod()
.attributes_Custom<UnitTestMethodReferenceAttribute>().first()
.MethodToInvoke
.invoke_No_Catch(this);
}
which I think is easier to read than
[Test]
[UnitTestMethodReference("folder_Exists")]
public void dirExists()
{
MethodBase method = MethodBase.GetCurrentMethod();
UnitTestMethodReferenceAttribute attr = (UnitTestMethodReferenceAttribute)method.GetCustomAttributes(typeof(UnitTestMethodReferenceAttribute), true)[0];
attr.MethodToInvoke.invoke();
}
in fact we should be able to refactor it to just
MethodBase.GetCurrentMethod().invoke_Related_Test(this);
...even better if we can replicate the MethodBase.GetCurrentMethod()
call
for example when we have
and there already is a good UnitTest for create_Folder there is no need to replicate a test for folder_Create, what we need is to have a way to confirm that create_Folder calls folder_Create.
I think the best way to do this will be with AST analysis, since with reflection we don't have easy access to the methods called by a particular method (unless we delve into the byte code)