Reorganisation of the test sources?

wolfganguhr

Hello

In addition to the reorganisation of the sources done by Christian and Matthias I suggest to reorganize to test data and the test name spaces too. Actually or source code base for the testing is very small and if ealier if less the price.

The revaluation code has split over a different set of souces. I've written

[] some code in Ict.Petra.Shared.MFinance, [/:m]
[] some more code in Ict.Petra.Server.MFinance.GL.WebConnectors[/:m]
[] changed two dialogs[/:m]
[] created a new dialog for it[/:m][/list:u]

I think this demonstrates that it is oversized if we put all the relevant test code into one set of classes in Tests.MFinance.GL.

I think the best is to parallize the test sources. Of Course the infrastructure files may differ somthing but I think the tests of the Ict.Petra.Server.MFinance.GL belongs into a file named like Test.Ict.Petra.Server.MFinance.GL and the routines in Ict.Petra.Server.MFinance.GL.WebConnectors shall be tested in Test.Ict.Petra.Server.MFinance.GL.WebConnectors

We have the Solution files
- [] client.sln[/:m]
  [] clientPlugins.sln[/:m]
  [] Common.sln[/:m]
  [] PetraTools.sln[/:m]
  [] ServerAdmin.sln[/:m]
  [] ServerPlugins.sln[/:m]
  [] Shared.sln[/:m][/list:u]
  
  But we only have one file Testing.sln.
  
  So in the very first step I recommend that we will organize the tests like
  - [] Tests.client.sln[/:m]
    [] Tests.clientPlugins.sln[/:m]
    [] Tests.Common.sln[/:m]
    [] Tests.PetraTools.sln[/:m]
    [] Tests.ServerAdmin.sln[/:m]
    [] Tests.ServerPlugins.sln[/:m]
    [] Tests.Shared.sln[/:m][/list:u]
    
    Best regars
    Wolfgang

christiankatict

Hi Wolfgang,

a re-organisation has already taken place when ThisG did the restructuring.

There are now a number of different Projects for the Tests - check out trunk in a separate directory if you haven't done so after ThiasG's changes and load Solution 'OpenPetra.sln', which is found in directory \trunk\delivery\projects\sharpdevelop3.

This re-organisation is only about Projects, and does not contain different Solutions for different Test targets. I am not sure we would need that, though - what might be handy would be an auto-generated 'Testing.sln' that would only contain the Projects of the Test targets.

wolfganguhr

Christian it is not only the problem that it is possible in a technical sense. It is more the problem that we have to decide for some basic rules of how to plan an implement the tests. Furthermore if I put a routine in the shared part, it would be a good idea to make shure that it runs on the server as on the client in the same way. Or if I write a specific user control it is sufficient to test the control once in a specific dialog created for the test only and not to to test it in the project which by accident was responsible for the birth of the control and so on.

But you are right, it is better to see the re organized files.

christiankatict

Hi Wolfgang,

yes, I see your point.

The re-organisation of the Unit Tests and a clear definition on how we ought to do them from that point onwards is on the to-do list of the openPETRA Architecture Team: we called the work item 'Unit test framework' and ThiasG will prepare a proposal for this. (See: sourceforge.net/apps/mediawiki/ ... iscussions)