locked
Nunit test code RRS feed

  • Question

  • Can any one write the nunit test code the following module

    public void DllCall()
            {

                String NameSpace, Class, Method;

                //get the DLL parameters from the configuration file

                NameSpace = ConfigurationSettings.AppSettings.Get("NameSpace");

                Class = ConfigurationSettings.AppSettings.Get("Class");

                Method = ConfigurationSettings.AppSettings.Get("Method");

                //Call the Dll

                Assembly assembly = Assembly.LoadFile(FilePath);

                object o = assembly.CreateInstance(NameSpace + "." + Class);

                Type type = o.GetType();

                MethodInfo methodInfo = type.GetMethod(Method);

                String output = Convert.ToString(methodInfo.Invoke(o, null));

             

            }

    Wednesday, June 1, 2011 6:05 AM

Answers

  • Hi,

    Sorry to say the code as it currently stands is not testable (especially for unit testing). Too many dependencies.


    "The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." - Fred Brooks
    Wednesday, June 1, 2011 8:43 AM
  • Hi,

    Ok with a bit of work the code that follows would be more testable. How do I know that... because I started with the test first.

        public class DllCallShould
        {
            public void InvokeAValidMethod()
            {
                DllParameters parameters = new DllParameters();  // set parameter values
                DllCall dllCall = new DllCall(parameters);

                string result = dllCall.Invoke();
                Assert.That(result, Is.EqualTo("what your expecting"));
            }
        }

    And that leads to this design... is it ideal... no, but it's a step in the right direction.

        public class DllCall
        {
            private DllParameters parameters;

            public DllCall(DllParameters parameters)
            {
                this.parameters = parameters;
            }

            public string Invoke()
            {
                object o = parameters.GetInstance();
                MethodInfo methodInfo = parameters.GetMethod();
                return Convert.ToString(methodInfo.Invoke(o, null));
            }
        }

        public class DllParameters
        {
            private Assembly Assembly { get; set; }

            public string AssemblyPath { get; set; }
            public string Namespace { get; set; }
            public string Class { get; set; }
            public string Method { get; set; }

            public MethodInfo GetMethod()
            {
                return this.GetInstanceType().GetMethod(this.Method);
            }

            public object GetInstance()
            {
                if (this.Assembly == null)
                    this.Assembly = Assembly.LoadFile(this.AssemblyPath);
                return this.Assembly.CreateInstance(this.Namespace + "." + this.Class);
            }

            private Type GetInstanceType()
            {
                return this.GetInstance().GetType();
            }
        }

    DllParameters could be inherited into a ConfigurationDllParameters class which loads the information from the configuration file.

    Like I said it's a start that still needs some work.

     

     

     


    "The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." - Fred Brooks
    Wednesday, June 1, 2011 11:53 AM

All replies

  • Please don't double post. Be patient someone who know this will answer your query

    http://social.msdn.microsoft.com/Forums/en-US/csharplanguage/thread/211d2fe3-d721-4137-9a52-a0f6a2cb71b0

    Meanwhile go through following article

    http://en.csharp-online.net/Unit_Testing_with_NUnit%E2%80%94Test_cases


    Thanks,
    A.m.a.L Hashim
    Microsoft Most Valuable Professional
    Dot Net Goodies
    Don't hate the hacker, hate the code

    Wednesday, June 1, 2011 6:23 AM
  • Hi,

    Sorry to say the code as it currently stands is not testable (especially for unit testing). Too many dependencies.


    "The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." - Fred Brooks
    Wednesday, June 1, 2011 8:43 AM
  • Agree with Derek.

    This method does too many things and has deep dependencies with external world. A warning is clearly the presence of the two comments (see Martin Fowler "Refactoring" to get the smell of it).

    You should isolate all the single passes and create via factories the objects representing the business. Then you could mock the parameters and make the constructors tests.

    Giuseppe

    Wednesday, June 1, 2011 9:49 AM
  • Hi,

    Ok with a bit of work the code that follows would be more testable. How do I know that... because I started with the test first.

        public class DllCallShould
        {
            public void InvokeAValidMethod()
            {
                DllParameters parameters = new DllParameters();  // set parameter values
                DllCall dllCall = new DllCall(parameters);

                string result = dllCall.Invoke();
                Assert.That(result, Is.EqualTo("what your expecting"));
            }
        }

    And that leads to this design... is it ideal... no, but it's a step in the right direction.

        public class DllCall
        {
            private DllParameters parameters;

            public DllCall(DllParameters parameters)
            {
                this.parameters = parameters;
            }

            public string Invoke()
            {
                object o = parameters.GetInstance();
                MethodInfo methodInfo = parameters.GetMethod();
                return Convert.ToString(methodInfo.Invoke(o, null));
            }
        }

        public class DllParameters
        {
            private Assembly Assembly { get; set; }

            public string AssemblyPath { get; set; }
            public string Namespace { get; set; }
            public string Class { get; set; }
            public string Method { get; set; }

            public MethodInfo GetMethod()
            {
                return this.GetInstanceType().GetMethod(this.Method);
            }

            public object GetInstance()
            {
                if (this.Assembly == null)
                    this.Assembly = Assembly.LoadFile(this.AssemblyPath);
                return this.Assembly.CreateInstance(this.Namespace + "." + this.Class);
            }

            private Type GetInstanceType()
            {
                return this.GetInstance().GetType();
            }
        }

    DllParameters could be inherited into a ConfigurationDllParameters class which loads the information from the configuration file.

    Like I said it's a start that still needs some work.

     

     

     


    "The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." - Fred Brooks
    Wednesday, June 1, 2011 11:53 AM