Question

I have a bunch of auto-generated code (coming from Ranorex GUI testing tool) that exposes a public interface like the one below:

public partial class MessageBoxPopupAppFolder : RepoGenBaseFolder
{
  // Ranorex.Button exposes public methods like Click()
  public virtual Ranorex.Button ButtonYes
  {
    get
    {
      return _buttonyesInfo.CreateAdapter<Ranorex.Button>(true);
    }
  }
}

My problem is that I’m in the process of writing an intermediate layer that will look like the code below, and I expect the users of that code to not bypass it by directly calling the autogenerated code (that would most probably break complex business rules)

public class MyAdapter
{
  private MessageBoxPopupAppFolder _myMessageBox;

  public static void Acknowledge()
  {
    // some complex business rules
    _myMessageBox.ButtonYes.Click();
  }
}

I have though of some solutions, but none seem really satisfactory:

• Manually (or through a script) modify auto-generated code to change visibility of Ranorex methods. That would imply a little namespace refactoring, and be difficult to maintain through code re-generation
• Link this code into a completely separate binary and communicate with it through a really private API. Lots of work ahead
• Implement some kind of code self-evaluation that would detect and report (as unit test failure) any “forbidden” use of that API

What could I do?

Just to clarify: I’m not concerned about keeping my middleware secret, just need to keep control over correct sequence on actual clicks.

EDIT: What I want to expose to my team members (users of my middleware) is a business-oriented API (like Acknowledge()). This is fine. What is not fine is that I can’t prevent the Ranorex raw API (Button.Click()) to come along.

Answer 1

1. If you want to be safe, your best choice would be your first one, using script to modified the auto-generated code. Add the script into your integrated build process to ensure this get runs all the time in case the code go regenerated.

2. Other wise you can set up FxCop rule to detect method calls that you don’t want to be used.

3. If the team is small and they are comfortable with following a design guideline. Then this is a matter of training team not to use the API. In your code review process your team will have to look for this issue. The drawback is that this is only a preventive action, your team member can still make mistake. QA and code review will be your best friend in this case.