0

We are writing a unit testing framework using MSTest so that we can test the AIF framework integration project we have.

We couldn't figure out a way to use mocks so our solution to this was to take a snapshot of the database at the start of the unit tests, then restore and dispose of it at the end using assembly initialise and cleanup.

Our test structure then makes a log on call to AX to create the data we need then log off and dispose. We then arrange the data we need and push it through the AIF service.

By the time we get to restoring the snapshot it falls over and says that it is not able to restore the database while other users are using the database. (even though we are cleaning up the service after its use). We can solve this by running another SQL query before it which loops through all the sessions and kills them (apart from the current one). This allows the DB to restore correctly but because we are not gracefully closing the sessions the AX Service thinks there is a problem and turns itself off which as you can imagine isn't very useful!

So we have a catch 22 situation here.

I haven't included any code in here because I don't think it would help any but if you think it will then let me know.

Please help me I am literally at the end of my tether!

Keithin8a
  • 961
  • 7
  • 32

1 Answers1

0

You should always separate tests and production database. It is not the good idea to use production database for test. And there are some reasons for it.

  1. OptimisticConcurrencyException – when you started to work with entity object during the test scenario, you can’t be sure that at the end of scenario entity that you work with wont changed by any other client. If it happened you’ll get exception which makes your test red and unstable.
  2. You can’t control each function call. When you use stubs and mocks you want to check some small piece of logic with data that you provide. If this data can change during test scenario you can’t be sure about test result.
  3. If you forgot to clean all data that you change in production database you’ll fill in you database with test data.

So the solution to these problems can be different.

  • You can simply use separate database on build server (just for tests). And fill it in it [TestInitialize] method (Don’t forget to clean it up in [TestCleanup]).
  • You can setup in memory database for testing In memory database in .net
  • You can try to mock you repository (I’m not sure what structure do you use in DAO). But if it is simple IRepository you can mock the interface that it provide and simply test it. For e.g.

    interface IRepository<T> where T : Entity
    {
     IQueryable<T> GetAll();
    
     bool Save(T entity);
    
     bool Delete(int id);
    
     bool Delete(T entity);
     }
    

Can be stubbed as following:

 [TestClass]
    public class UnitTest1
    {
        private IRepository<Entity> _repository;
        private SomeService _target;

        [TestInitialize]
        public void SetUp()
        {
            _repository = MockRepository.GenerateStub<IRepository<Entity>>();
            _target = new SomeService(_repository);
        }


        [TestMethod]
        public void TestMethod1()
        {
            _repository.Stub(x => x.GetAll()).Return(new List<Entity>().AsQueryable());

            //Test your target
        }
    }
Community
  • 1
  • 1
Andrei
  • 1
  • 1
  • The problem is, with AX a lot of the configuration is done in various different tables within the database so we actually need to have the Database there. We are trying to create a system now where we essentially have the behaviour of the snapshots but with code itself. It isn't a very clean solution but it should be suitable for a development environment. – Keithin8a Nov 07 '14 at 14:16