Unit tests for an add'in

[Guillaume]

Hi,

I started writing an add'in in C# and would like to define unit tests.
I'd like to test "Class1.method1(Element e)" however I cannot find any way to create an Element (e.g. a class) on its own.

example :
namespace unittests
{
        [TestClass]
        public class GFTests
        {
            [TestMethod]
            public void TestMethod1()
            {
               Element uc1 = new Element(); //I need to define an element named use case 1 of type use case -> this constructor doesn't work
               uc1.Name = "Use Case 1";
               uc1.Type = "Use Case";
               Class1.method1(uc1);
               Assert.Equals(uc1, "test"); //method1 should have renamed uc1 to test

            }
   }
}

Is there any way to get this to work?

Thanks

[Geert Bellekens]

Not to my knowledge.

Geert

[Uffe]

Nor mine. You'll have to take the collection as an argument, as in

Code: [Select]

[TestMethod]
public void TestMethod1(Collection elements)
{
    Element uc1 = elements.AddNew("Use Case 1", "Use Case");
    elements.Update();
    elements.Refresh();
    Class1.method1(uc1);
    Assert.Equals(uc1, "test"); //method1 should have renamed uc1 to test
}This, of course, leaves the element in the collection regardless of the success or failure of the test, so probably you'll want to take the element as an argument instead and do the creation and deletion outside.


/Uffe

[Guillaume]

Thanks for your replies. I tried Uffe's suggestion, but I'm getting the error message "No arguments were provided".

EA.Collection class doesn't provide any constructor so I'm not sure I can achieve the unit test for the add'in.

[qwerty]

You can't construct a collection in EA but only use AddNew, GetAt and Delete(At) to modify its contents.

q.

[Uffe]

Essentially, there are no constructors in the API. Instead, Collection.AddNew() is used as a factory method. The Collection class is generic and there is to my knowledge no way of checking what type of object (package, element, attribute, etc) it contains in runtime -- you simply have to know which is which.

The contents of the repository are accessed recursively. A newly created repository contains one single root-level package (default name "Model"), which you can retrieve from the Repository.Models collection.

The method I suggested requires an element Collection from a non-root package. Root level packages can only contain packages ("view" packages in the project browser), but those packages in turn can contain elements and diagrams as well as further child packages. Thus, trying AddNew() on the Elements collection of a root-level package will cause an error.

So it's a question of how much you want to create within the context of the test method. You could go as far as creating the repository itself (Repository.CreateModel()), but that can take several seconds which is probably not acceptable in a unit test so you'll most likely want to do that as part of your test initialisation.

Similarly, you could create the view-level package inside the test method. This doesn't take as anywhere near as much time but for convenience I'd push that to the initialisation as well.

So something along the following lines should do it.

Code: [Select]

public Package InitTestRepository(Repository repository, string eapFileName)
{
    repository.CreateModel(cmEAPFromBase, eapFileName, 0);
    Package rootPackage = repository.Models.GetAt(0);
    return rootPackage.Packages.AddNew("Test View", "Package");
}During initialisation, store the result in a member or global variable, then simply pass thatVariable.Elements to test methods which create elements, thatVariable.Packages to methods which create packages, etc.