Unit Testing and Performance Using Entity Framework 4.0 Tommy Hörnlund January 24, 2013 Master’s Thesis in Computing Science, 30 credits Supervisor at CS-UmU: Jan-Erik Moström Examiner: Fredrik Georgsson Umeå University Department of Computing Science SE-901 87 UMEÅ SWEDEN Abstract POÄNGEN is a web application for rent management. The core of the application is a module that performs rent calculations. In the past the application relied heavily on business logic in stored procedures that made the program hard to test and maintain. The purpose of this thesis was to find a new method for combining unit testing and data access. A new implementation of the rent calculation had to be created that was easier to test, maintain and have good performance. This thesis shows how to combine data access and unit tests using Entity Framework 4.0, an object relational mapping framework from Microsoft. The new module uses the Repository and Specification design patterns to create a data abstraction that is suitable for unit testing. Also the performance of Entity Framework 4.0 is evaluated and compared to traditional data loading and it shows that Entity Framework 4.0 severely lacks in performance when loading or saving large amounts of data. However the use of POCO entities makes it possible to create optimized functionality for time critical data access. ii Contents 1 Introduction 1 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Goals & Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 POÄNGEN 3 2.1 Utility principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3 Residential unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4 Apartment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.5 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.6 Score . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.7 Rent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.8 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3 Entity Framework 7 3.1 Entity Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 LINQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4 Loading Related Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.5 Change Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Testability 11 13 4.1 Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2 Unit of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3 POCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4 Mocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.5 Inversion of Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.6 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 iii iv CONTENTS 5 Result 5.1 Overview . . . . . . . . . . 5.2 Entity Data Model . . . . . 5.3 POCO . . . . . . . . . . . . 5.4 Specification . . . . . . . . . 5.5 FetchStrategy . . . . . . . . 5.6 Repository . . . . . . . . . . 5.7 Calculation . . . . . . . . . 5.8 Dependencies . . . . . . . . 5.9 Data Access . . . . . . . . . 5.10 Data Persistence . . . . . . 5.11 Unit Tests . . . . . . . . . . 5.11.1 Testing Data Access 5.11.2 Test Data . . . . . . 5.11.3 Mocking . . . . . . . 5.11.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 17 18 19 19 20 20 21 22 23 23 23 24 25 25 25 6 Performance 6.1 Test Data . . . . . . . . . 6.2 Test Application . . . . . 6.3 Execution . . . . . . . . . 6.4 Result . . . . . . . . . . . 6.4.1 Calculation time . 6.4.2 Memory Usage . . 6.4.3 Persistence . . . . 6.4.4 Legacy Calculator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 29 29 29 30 30 30 31 33 . . . . . . . . 7 Conclusions 35 7.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 8 Acknowledgements 37 References 39 List of Figures 3.1 3.2 An example database diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . The entities that are mapped to the database tables in figure 3.1 . . . . . . . 5.1 5.2 5.3 Conceptual overview of the system . . . . . . . . . . . . . . . . . . . . . . . . 18 The real and the mock context implements the same interface . . . . . . . . . 19 Calulation module dependencies . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.1 6.2 6.3 6.4 6.5 Data loading comparison . . . . . . . . . . . . Memore usage comparison . . . . . . . . . . . Entity Framework persistance performance. . Entity Framework persistence memory usage Comparison with legacy rent calculator . . . v . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8 30 31 32 32 33 vi LIST OF FIGURES List of Tables 2.1 2.2 2.3 2.4 2.5 2.6 Common apartment properties. . . . . . . . . . An example model. . . . . . . . . . . . . . . . . Two apartments with different property values. Property values converted to score . . . . . . . Formula calculated score . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . vii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4 5 6 6 6 viii LIST OF TABLES Listings 3.1 3.2 3.3 3.4 3.5 3.6 3.7 4.1 4.2 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 Using LINQ to query a list of integers. . . . . . . . . . . Using LINQ to query an entity collection. . . . . . . . . Loading related entities by including them in the query. Explicitly loading related entities after the query. . . . . Loading related entities with lazy loading enabled. . . . Loading related entities before the query is executed. . . Saving changes to the context . . . . . . . . . . . . . . . Regular dependency . . . . . . . . . . . . . . . . . . . . Inversion of Control . . . . . . . . . . . . . . . . . . . . The calculation module interface . . . . . . . . . . . . . The specification interface . . . . . . . . . . . . . . . . . An excerpt from the generic repository interface . . . . Ordinary object instantiation. . . . . . . . . . . . . . . . Dependency injection using a factory lambda expression. Specification for an active apartment. . . . . . . . . . . Unit testing the Specification for an active apartment. . Mock example . . . . . . . . . . . . . . . . . . . . . . . . IFormulaCalculator interface . . . . . . . . . . . . . . . IModelLayoutCalculator interface excerpt . . . . . . . . Example unit test . . . . . . . . . . . . . . . . . . . . . ix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9 10 10 10 10 11 15 15 17 20 20 22 22 24 24 25 26 26 27 x LISTINGS Chapter 1 Introduction TRIMMA is an IT company focusing on solutions for business management and decision making software. One if its major products is POÄNGEN (translates to ”Score”), a complete solution for rent management according to the utility principle. An explanation of the utility principle can be found in section 2.1. POÄNGEN started out as a small and simple application, but it has quickly grown in both functionality and number of customers. It is becoming harder and harder to maintain and develop the application and new development methods has to be found in order to ensure the future of POÄNGEN. A core part of the application is the rent calculation module. It is a data heavy process where large amounts of data is brought together to calculate the rent for each apartment. The current implementation suffers from many issues. The first problem is that it is hard to test the correctness of the module. The only way to know that it works correctly is because it has worked in the past. This means that the module cannot easily be extended, because the correctness cannot be verified if a change is made. Another issue is performance. With larger and larger customers the system cannot handle the tens of thousands of apartments these companies manage. If a new system design is proposed, it has to be highly efficient. 1.1 Overview Chapter 1 contains the background and problem statement. Chapter 2 is a brief introduction to the problem domain. Chapter 3 is an overview of Entity Framework, the object relational mapping framework used in this project. Chapter 4 contains a theoretical study about testability and Entity Framework. Chapter 5 describes the final application that was created. Chapter 6 contains a performance study on the resulting application. Chapter 7 contains the discussion of the results and conclusions. 1 2 1.2 Chapter 1. Introduction Problem Statement The task is to create a new rent calculation module with automated testing. The possibility to add new features should be taken into consideration as well as the performance of the calculation. A large part of the problem is that existing calculation logic reside in the database in the form of stored procedures. It is not possible with the current tools to automatically test this functionality. If a change is made there is no safeguard that the previous functionality is not altered. The problem is to move this logic to the application code without loosing performance. Presently POÄNGEN is using an object relation mapping (ORM) framework known as dOOdads[16]. This framework however is obsolete and no longer maintained. Therefore another ORM framework will be used, Microsofts Entity Framework 4.0[14]. Part of the project will be to evaluate the testability and performance of Entity Framework. 1.3 Goals & Purpose The purpose is to develop a method to incorporate automated testing in the development process. The method should be evaluated to determine if it is suitable for the existing application as well as in future development. The goal is to develop software that is easier to maintain and modify, without introducing new bugs in the existing functionality. Chapter 2 POÄNGEN This chapter is a brief introduction to the utility principle. The utility principle is the underlying principle of POÄNGEN, a complete solution for rent management. 2.1 Utility principle The idea behind the utility principle is to provide an alternative to market prices. The difference in price between apartments should be easily explainable because of different standards on the apartments[3]. In Sweden a landlord is governed by law to use the utility principle[7]. The method used in POÄNGEN is based on work by the Swedish Association of Public Housing Companies (SABO)[3]. The basic idea is that a score is calculated for each apartment and then the current rent is redistributed relative to the score to calculate the new rent. This means that the total income remains constant while some apartments get increased rent and others decreased. 2.2 Properties To describe the different aspects of the apartments a number of properties are defined. Properties can be of different data types; string, numeric, boolean and predefined values. The most common properties has been defined by SABO[3] while others has to be chosen based on experience. Some of the common properties can be seen in table 2.1. Properties can also be undefined, represented by a null value. Table 2.1: Common apartment properties. Name Data type Possible values Area Apartment type Balcony Address Location Numeric Predefined Boolean String Predefined Real numbers 1ROK, 2ROK, 3ROK yes or no Any string A, B, C 3 4 2.3 Chapter 2. POÄNGEN Residential unit Apartments are contained in groups called residential units. A unit usually consist of a single building or several very similar buildings. Properties such as building year, surroundings and distance to different services can be associated with residential units. 2.4 Apartment The apartment score is calculated from the number of rooms and the type of kitchen. For example, one room and kitchenette receives 24 points, while two rooms and a regular kitchen receives 40 points. This score is added to the area of the apartment and this becomes the total score for the apartment. The apartment score assumes that the apartment has all the standard equipment of a regular apartment. If some part of the apartment differs from the standard an adjustment score has to be added. For example, if the balcony is extra large the apartment should gain extra points, while if the balcony is extra small or missing the apartment should loose points. The different types of scores are described in section 2.6. 2.5 Model A model is a mapping from properties to points, different property values can be assigned different points. An example model can be seen in table 2.2. Each property is also assigned a formula alias. All points with the same formula alias are summed and substituted into the corresponding variable in the formula, described in the next section. Table 2.2: An example model. The apartment type has a fixed score for each possible value. The area property is a numerical property so it can be directly converted to points. Formula alias Property Value Points A A A Apartment type Apartment type Apartment type 1ROK 2ROK 3ROK 34 40 44 A Area X X B B Balcony Balcony Yes No 0 -5 C C C Location Location Location A B C 35 33 21 2.6. Score 2.6 5 Score There are three different types of points in the model. The A score is known as the apartment score. It is a measure of the size and number of rooms in the apartment. Each apartment is assumed to satisfy the minimum standard requirements. For example, rooms should have at least one window and heating should be included in the rent. The second type is the B score, called the adjustment score. If the apartment differs from a standard apartment an adjustment has to be made. For example if an apartment has no balcony a negative score will be added to the B score. The final type is the C score, called the residential unit score. This is the score for all properties that are shared by all apartments in a residential unit. The desirability of the building location can be one such property. The total score is calculated by taking the residential unit score C and adding 100. This score is then multiplied by the apartment score A. Finally the adjustment score B is multiplies by 100 and added to the product. The final formula can be seen in equation 2.1. Total score = (100 + C) × A + (100 × B) 2.7 (2.1) Rent To convert from points to rent the total income from all apartments are divided by the sum of the score for all apartments, see equation 2.2. Factor = Total income Sum of all scores (2.2) The resulting factor is then multiplied by the score of the apartment to calculate the rent, equation 2.3. Apartment rent = Score × Factor 2.8 (2.3) Example An example is two apartments having the same rent of 3000 SEK, but different standard. With the utility principle the rent should be redistributed to reflect the differences of the apartments. Table 2.3: Two apartments with different property values. Value Apartment one Area Type Balcony 32 2ROK Yes Apartment two 30 1ROK No 6 Chapter 2. POÄNGEN The first apartment in table 2.3 has an area of 32 m2 , two room and kitchen (2ROK) and a balcony. The second apartment has an area of 30 m2 , one room and kitchen (1ROK) but no balcony. Using the model in table 2.2 the properties can be converted to points in table 2.4. Table 2.4: The score for each property in table 2.3. Points Apartment one Area Type Balcony Apartment two 32 40 0 30 34 -5 Again using the model the A, B and C score can be calculated in table 2.4. The final score is calculated by using equation 2.1. Table 2.5: The score for the two apartments. The total score is calculated using the formula (100 + C) × A + (100 × B). Points A B C Total Apartment one Apartment two 72 0 0 7200 64 -5 0 5900 Apartment ones type is worth 40 points. Added with the area the A score becomes 72. The total points become (100 + 0) × 72 + (100 × 0) = 7200. The second apartment receives (100 + 0) × 64 + (100 × −5) = 5900. 60 The factor becomes 3000+3000 7200+5900 = 131 . Now the factor can be multiplied with the new score to calculate the new rent. Table 2.6: Example Apartment one Points Old rent New rent 7200 3000 SEK 3298 SEK Apartment two 5900 3000 SEK 2702 SEK Note that the sum of the new rents are the same as the sum of the old rents. It has been redistributed to better reflect the utility of the apartments. Chapter 3 Entity Framework According to the requirements Entity Framework had to be used, the reason being that the framework was already in use for other projects at the company. Entity Framework is an object relation mapping framework from Microsoft that is included in the .NET framework[14]. The version used for this project is Entity Framework 4.0. The basic idea of Entity Framework is to eliminate the impedance mismatch between business logic and data representation. This is done using the Entity Data Model (EDM). 3.1 Entity Data Model The Entity Data Model has two basic components. – Entities are strictly typed data structures that contains the record data and an identifier key. – Relationships are associations between entities. More advanced features of the EDM are inheritance and complex types[14], but these are not used in this project. The Entity Data Model should be created to reflect the structure of the business objects used in the application. It may be necessary to create different data models for different parts of the application, while still using the same database. 3.2 Mapping To populate the data model with data from an actual relational database a mapping has to be created. Entities can be mapped to database tables, but several tables can also map to a single entity or a table can be split up into several entities. In figure 3.1 the Employee and ContactInfo tables are combined into a single entity. The mapped entities can be seen in figure 3.2. The Company entity can be accessed from a property on the Employee entity, and the Company entity contains a list of all employees associated with the company. When accessing the entities in the application code Entity Framework will automatically fetch data from the database and populate the in-memory data structure. 7 8 Chapter 3. Entity Framework Company Employee Employee PK Company EmployeeID PK CompanyID Salary FK1 ContactInfoID FK2 CompanyID Name ContactInfo PK ContactInfoID Name Adress Phone Figure 3.1: An example database diagram. The dashed boxes show the entities that the database tables are mapped to. Employee +Salary : decimal +Name : string +Adress : string +Phone : string +Company : Company 0..* 1 Company +Name : string +Employees : List< Employee > Figure 3.2: The entities that are mapped to the database tables in figure 3.1. 3.3. LINQ 3.3 9 LINQ Instead of using SQL query strings to query the entity model the C# language has introduced a new feature called Language Integrated Query (LINQ). LINQ can be used to query a number of different data sources like databases, collections, XML documents and entity models using the same syntax. In listing 3.1 a LINQ query is made against a list of numbers. All numbers less or equal to five are selected and the numbers are sorted in ascending order. Listing 3.1: Using LINQ to query a list of integers. int [] numbers = new int [] {5 , 7 , 1 , 4 , 9 , 3 , 2 , 6 , 8}; var smallnumbers = from n in numbers where n <= 5 orderby n select n ; foreach ( var n in smallnumbers ) { Console . Write ( n ) ; } OUTPUT : 12345 The same syntax is used to load entities from the database and when used with entities it is usually referred to as LINQ to Entities. Each entity type is represented as a collection and all collections are contained in an ObjectContext class. The object context act as a repository and a unit of work, concepts described in chapter 4. For now the important thing is that entities are accessed through a collection, in the same way as the number example in listing 3.1. Listing 3.2 shows an example where LINQ is used to query the company context for all employees named ”Bob”. Listing 3.2: Using LINQ to query an entity collection. CompanyContext companyContext = new CompanyContext () var bobs = from e in companyContext . Employees where e . Name == " Bob " select e ; 10 Chapter 3. Entity Framework 3.4 Loading Related Entities When loading an entity related entities can be loaded as well, as defined by the relationships in the EDM. There are several ways related entities can be loaded. 1. Specified in the query 2. Explicit loading 3. Lazy loading 4. Eager loading The first method is used in listing 3.3 and it references the related fields in the query and selects them. Listing 3.3: Loading related entities by including them in the query. var result = from e in companyContext . Employees select new { Name = e . Name , Company = e . Company . Name }; In listing 3.4 the employee entity is loaded first, then the company navigational property of the employee is explicitly loaded. The First() method simply returns only the first employee in the result set. This methods requires two round trips to the database to retrieve the data. Listing 3.4: Explicitly loading related entities after the query. var employee = ( from e in companyContext . Employees select e ) . First () ; employee . Company . Load () If the lazy loading option is enabled in Entity Framework there is no need to explicitly load the related entity, it is automatically loaded when it is accessed like in listing 3.5. This too requires two round trips to the database and care must be taken when accessing a navigational property. If for example lazy loading happens inside the loop iterating over a list of employees an SQL query will be executed for every iteration. Listing 3.5: Loading related entities with lazy loading enabled. var employee = ( from e in companyContext . Employees select e ) . First () ; Company company = employee . Company ; The final method in listing 3.6 is eager loading. Here the Company related entity is included just after the LINQ query. This only creates a single SQL query joining the tables together. Listing 3.6: Loading related entities before the query is executed. var result = ( from e in companyContext . Employees select e ) . Include ( " Company " ) ; 3.5. Change Tracking 3.5 11 Change Tracking When a change is made to an entity the change is automatically tracked by Entity Framework. To persist the changes to the database the SaveChanges method is called on the context object, as in listing 3.7. Listing 3.7: Persisting the entity changes made to the object context. var employee = ( from e in companyContext . Employees select e ) . First () ; employee . Salary += 1000; companyContext . SaveChanges () ; 12 Chapter 3. Entity Framework Chapter 4 Testability The focus of the study has been on the subject of testability, specifically how to unit test data access code. Because one of the requirements was to use Microsoft Entity Framework 4.0 a lot of effort was put into finding information about testability when using EF4. In an articled published on MSDN Scott Allen demonstrates some common unit testing techniques that can be applied to EF4 [1]. Allen argues that extensive unit testing is a valuable tool to developer teams. However, the effort in creating these unit tests are related to the testability of the code. Therefore Entity Framework 4.0 was designed with testability in mind. Allen presents two metrics that will always be exhibited by highly testable code. The first one is observability. If a method is observable, it is easy to visually observe the output of the method, with a given input. Methods with many side effects are hard to observe. The other metric is isolation. When you unit test a method you only want to test the logic inside the method. But if the method depends on some external resource, for example a network socket or database, the unit test might fail if the resource is off line. The resource might also take a very long time to respond, leading the automated test to take a very long time to run. To achieve testable code a separation of concerns should be maintained. This concept was termed the Single responsibility principle by Robert C. Martin [11]. It is based on the concept of cohesion and can be summarized as: “There should never be more than one reason for a class to change”. In this case the logic should reside in one class or module and the external resource access should reside in another. They can then be unit tested in isolation. These metrics presented by Allen are very basic metrics but they can easily be applied to any newly developed code. The concept will also be repeated when other patterns are discussed, so these metrics will be used to evaluate the resulting code of the project. 4.1 Repository Allen goes on to explain some common abstractions that are useful for abstracting data persistence. One very common abstraction is the Repository pattern. This design pattern has been documented by Martin Fowler in his book Patterns of Enterprise Application Architecture[5] and a short overview of the pattern can also be found on his website[6]. The repository pattern is very commonly used, both for unit testing and other uses. According to Fowler a repository “mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects”. Allen says that this isolates 13 14 Chapter 4. Testability the details of the data persistence, and that it fulfills the isolation principle required for testability. However, he also adds that the interface for a repository shouldn’t contain any operations for actually persisting the objects back to the data source. In the spirit of the single responsibility principle, a separate structure should be used, and he presents the Unit of Work pattern. 4.2 Unit of Work The Unit of Work pattern is also described by Martin Fowler in his book Patterns of Enterprise Application Architecture[5] and on his website[6]. Allen mentions that the unit of work pattern should be a familiar pattern for .NET developers, because it has been used in the ADO.NET DataSet class. It has the ability to handle update, delete and insert operation on database table rows. It is however tightly coupled to database logic. The goal is to isolate the specifics of data persistence. This is why Allen argues that the unit of work pattern is required. The default behaviour in Entity Framework 4.0 is to create a class extending the ObjectContext class. The object context serves as both a repository for generated entities as well as a unit of work. There is no interface defined for the object context, which is a problem when you want to achieve isolation and testability. Fortunately there exists several extensions for generating entities which can be used instead of the default code generator. Allen uses a template that generates POCO (Plain Old CLR Objects). 4.3 POCO The POCO concept originates from the Java POJO classes (Plain Old Java Objects). The POCO object is independent of the data source and contains only data and business logic. This is known as Persistence Ignorance. According to Allen objects using POCO classes are easier to test than entities that include information about persistence. Julie Lerman mentions two flavours of POCO entities on her blog[9] which is the same information as in her book Programming Entity Framework[10]. The first type is Data Transfer Objects (DTO) that are unable to notify the object context of any changes made to the entities. The changes to the context is only checked before a commit is made on the context. Lazy loading is not possible with this POCO type. If all the properties and associations of the POCO class is declared virtual a second type of POCO entites are possible. When the context creates the POCO entity it actually creates a proxy class that overrides the methods of the POCO class and provides feedback to the context when the POCO is manipulated. This makes it possible for the context to intercept if an association is accessed that is not yet loaded. It can then be lazily loaded on demand. One interesting detail is that Lerman puts the generated POCO entities in a separate class library, allowing to create different applications that are only connected by the POCO entities. 4.4 Mocking One of the biggest thresholds in beginning unit testing is how to isolate a unit before testing it. Tim Mackinnon, Steve Freeman and Philip Craig used mock objects to isolate units in their paper[20]. According to them, what makes unit testing hard is that the units are tested from the outside. 4.5. Inversion of Control 15 Using mock objects it is possible to test code in isolation. Mock objects replace the application code with dummy classes that emulate the real objects, but provide a much simpler implementation that can be set up with data relevant to the unit tests. If the mock objects become too complex this is an indication that the application code itself is too complex and requires refactoring. 4.5 Inversion of Control In his examples Allen creates a class that is dependent upon the interface of a unit of work class like in listing 4.1. Because it uses an interface he can create another implementation of the unit of work class that has no database connection, it just uses hard coded in memory data known as a fake class. To be able to switch implementation the creation of the unit of work class is moved from the constructor to a member variable that can be sent to the constructor like in listing 4.2. Listing 4.1: The Controller class depends on the UnitOfWork class. class Controller { UnitOfWork unitOfWork ; Controller () { this . unitOfWork = new UnitOfWork () ; } } Listing 4.2: Inversion of control is used to break the dependency. class Controller { IUnitOfWork unitOfWork ; Controller ( IUnitOfWork uow ) { this . unitOfWork = uow ; } } This is a very simple implementation of a pattern known as Dependency Injection. As Allen mentions this is only a simple example, a real project would use a more complex method to automate the process of dependency injection. When creating the data needed in the unit test Allen creates a class that initializes test data intended to be used across multiple test suits. This is a design pattern known as Object Mother, described by Schuh and Punke[18]. They show that it can be a very useful pattern for unit tests that requires data that closely resembles real data. However, as mention by Martin Fowler[4], it creates a strong coupling between tests that use the same test data. Changes to a test that requires the test data to change might affect other tests. The pattern still seems very useful, but it is slightly outside the scope of this thesis. 16 4.6 Chapter 4. Testability Unit Testing For unit testing Lerman uses mock contexts that implement the context interface[9]. Instead of accessing a database the mock context returns mock object sets that read its data from an internal list of POCO entities. Several mock contexts are created, for example one with valid data and one with invalid data. This approach is similar to using the ObjectMother pattern mentioned in section 4.5, and it suffers the same drawback that the tests becomes strongly connected through the shared test data. The practical use of testability is the ability to unit test the code. R. Venkat Rajendran is writing in a paper[19] about the impact of testing in general and the benefits and drawbacks of unit testing. One of the benefits is the ability to test one part of the code without having to rely on other parts being available. This makes it possible for several programmers to work on and create unit tests simultaneously. Unit testing also makes it possible to debug a very confined piece of code. It is also possible to test special test cases with state that is very hard to set-up for the whole program. The overall structure of the code is also improved when unit testing is enforced. Unit testing is the most cost effective type of testing, because it occurs in the early stages of development. Some of the drawbacks with unit testing according to Rajendran is that unit testing is boring. The solution to this is to provide better tools to automate repetitive task. Another problem is that documentation of test cases is rarely done in practise. This makes it hard to modify existing test cases. Because lots of stubs have to be created in order for a unit test to function, the test code is in many cases larger then the production code. Stub code can have bugs as well. Some of these drawbacks can be resolved, like enforcing code conventions that create self-documenting code. Also if the code has a high testability the unit tests will be less complex, reducing the number of bugs in the test code. The effort of writing full coverage unit tests will always be great, and a careful decision has to be made if the program is important enough to justify such an effort. Chapter 5 Result This chapter describes the final implementation of the application. The module has a service oriented interface shown in listing 5.1. There is a method for calculating the rent for a set of apartments, given the id of a model, and to calculate the rent for all apartments. There is also event handlers to receive feedback about the calculation progress. Listing 5.1: The calculation module interface. public interface I O b j e c t C a l c u l a t i o n S e r v i c e { event P u m a C a l c u l a t i o n S e r v i c e . ObjectService . O b j e c t C a l c u l a t i o n S e r v i c e .←CalculationProgressHandler CalculationProgress ; event P u m a C a l c u l a t i o n S e r v i c e . ObjectService . O b j e c t C a l c u l a t i o n S e r v i c e .←C a l c u l a t i o n E v e n t H a n d l e r C al c ul a ti o nE v en t ; void Ca l cu l at e Ob j ec t s ( IEnumerable < int > objectIDs , int modelID , string ←ca lcul atio nNam e ) ; void C a l c u l a t e A l l O b j e c t s ( int modelID , string c alcu lat ionN ame ) ; } 5.1 Overview A conceptual overview of the architecture can be seen in figure 5.1. The business logic is separated from the data access layer and only depends on the POCO entities. The generic query repository uses specifications and fetch strategies to fetch entities from the context. The resulting entities can then be used in the business logic module. The data access and business logic is wrapped in a service layer that acts as a layer between the whole calculation module and the service consumer, in this case a web application. 17 18 Chapter 5. Result Service GenericRepository Logic Context Specification FetchStrategy POCO Figure 5.1: Conceptual overview of the system. 5.2 Entity Data Model The core of the data access layer is the Entity Data Model. It is semi-automatically generated from the current development database and each table is directly mapped to an entity object. The foreign key relations are also included as associations between entities. Because of legacy artefacts in the database some minor adjustment has to be made to the data model, for example relations without foreign key constraints has to be added manually. A T4 template[12] is used to generate the context. T4 templates are a combination of program code and a scripting language that’s used to output program code. A mock context and mock object set is also generated, to allow mocking of dependencies in the unit tests. Figure 5.2 shows how the real context and the mock context implement the same interface. This allows for unit tests that replace the real data access with mock data access. 5.3. POCO 19 «interface» IPumaModelContext «interface» IObjectSet +Entities () : IObjectSet <Entity> MockObjectSet PumaModelContext +Entites () : IObjectSet <Entity> PumaModelContextMock +Entities () : MockObjectSet <Entity> ObjectContext Figure 5.2: The real and the mock context implements the same interface. 5.3 POCO The POCO entities were generated with the same template as the context. They are placed in a separate project, having no references to any other project. This makes it possible to write business logic that is not dependent on the data source. Although the POCO entities are generated from a database, this is a one-time operation. When the classes are in place, instances can be created at any time, without requiring a database connection. 5.4 Specification A specification checks if an entity satisfies a certain condition. The condition is specified as a LINQ expression. The same expression is used both to check if an in-memory entity satisfies the specification, but it is also used in LINQ to Entities (3.3) to receive entities from the database. This eliminates any duplicate code between accessing the in-memory model and 20 Chapter 5. Result accessing the database, as well as isolating the query expression so it can be unit tested. The most important method in listing 5.2 is IsSatisfiedBy. It determines if an entity satisfies the LINQ expression in the specification. The Predicate property simple return the internal expression. There is also methods to combine the specifications using boolean logic. Listing 5.2: The specification interface public interface ISpecification <T > { Expression < Func <T , bool > > Predicate { get ; } bool IsSatisfiedBy ( T entity ) ; ISpecification <T > And ( ISpecification <T > other ) ; ISpecification <T > Or ( ISpecification <T > other ) ; } 5.5 FetchStrategy FetchStrategy is a very simple class that contains the associated entities that should be loaded when the root entity is loaded. This is the same feature as Include in Entity Framework (3.4), but wrapped in its own class. The fetch strategy is used together with the specification when loading entities from the repository, as can been seen in listing 5.3. 5.6 Repository The repository is based on a generic repository created by Will Beattie[2]. The basic idea when loading an entity is to provide a specification of the same entity type. Only entities satisfying the specification will be loaded. Part of the interface of the repository can be found in listing 5.3. It contains methods to load a single entity matching a specification, load all entities matching this specification and to check if any entity exists that matches the specification. In addition a FetchStrategy can be supplied. It determines if any associated entities should be loaded as well. This allows Entity Framework to load the associated entities joined in a single query, decreasing the number of queries required thus increasing performance. Listing 5.3: An excerpt from the generic repository interface public interface I G e n e r i c Q u e r y R e p o s i t o r y { T Load <T >( ISpecification <T > spec ) where T : class ; IEnumerable <T > LoadAll <T >( ISpecification <T > spec ) where T : class ; bool Matches <T >( ISpecification <T > spec ) where T : class ; T Load <T >( ISpecification <T > spec , IFetchStrategy <T > fetchStrategy ) where T : class ; ... } 5.7. Calculation 5.7 21 Calculation The logic module handles all aspect of the rent calculation. The class dependency diagram can be seen in figure 5.3. It is important to note that all dependencies are actually dependencies on the interface. Another important point is that the module is not aware of any part of the data access modules. It uses the POCO entities as if they were in-memory object graphs. Calculator ObjectCalculator FormulaCalculator RentCalculator ModelLayoutCalculator AdjustmentValueCalculator CalcValueCalculator DependencyCalculator OPICalculator Figure 5.3: The depenency between classes in the calculation module. 22 Chapter 5. Result 5.8 Dependencies Each dependency between two classes is implemented using dependency injection. Instead of instantiating an object the usual way, as in listing 5.4, a factory method is used in listing 5.5 to instantiate the dependency. Listing 5.4: Ordinary object instantiation. public class F o r m u l a C a l c u l a t o r : I F o r m u l a C a l c u l a t o r { public decimal MyMethod () { IModelLayoutCalculator modelLayoutCalculator = new M o d e l L a y o u t C a l c u l a t o r () ; ... } } Listing 5.5: Dependency injection using a factory lambda expression. public class F o r m u l a C a l c u l a t o r : I F o r m u l a C a l c u l a t o r { public Func < IModelLayoutCalculator > M o d e l L a y o u t C a l c u l a t o r F a c t o r y = () = > new M o d e l L a y o u t C a l c u l a t o r () ; public decimal MyMethod () { IModelLayoutCalculator modelLayoutCalculator = M o d e l L a y o u t C a l c u l a t o r F a c t o r y () ; ... } } The factory method in listing 5.5 may look complex if you are unused to the the syntax, but it is simply a first class function stored in the member variable ModelLayoutCalculator Factory. The function is assigned a default value that uses the C# language feature of lambda expressions to create a method that has no input (the empty parenthesis) and returns a new instance of the ModelLayoutCalculator class. To invoke the function the variable name is used, followed by parentheses. This implementation differs from the one found in the study in section 4.5. In this case the only reason for using dependency injection is to replace the real dependency with a mock object. In the actual application the dependencies are hard coded. Therefore the factory methods allows a default dependency to be implemented, and this makes the classes easier to use, because the dependencies doesn’t have to be sent to the constructors. If dependency injection is used to allow different implementations in the actual production code this method is likely insufficient. 5.9. Data Access 5.9 23 Data Access The generic repository and specification is only one way to load the data. To measure the performance of this approach four other loading methods has been implemented to be used as a reference. – Using LINQ to query directly against the object sets, as described in chapter 3. – Using a SQL query string with ADO.NET. – Using a stored procedure and calling it using ADO.NET. – Using Entity Framework function import to create a strongly typed result object from the stored procedure. 5.10 Data Persistence To save the result from the calculation to the database, instances of POCO classes that are to be saved to the database are created and added to the object context. The result is then persisted by Entity Framework to the database. The test in section 6.4.3 showed that this method was highly inefficient and had to be abandoned. Instead the SqlBulkCopy[13] class was used that can efficiently copy data from any data source to a database. 5.11 Unit Tests All these techniques come together in the unit tests. Because the classes are decoupled from both the data access layer and from each other the unit tests become very simple to write. The framework used for unit testing is Visual Studio Unit Testing Framework [15]. This framework is built into Microsoft Visual Studio. 24 Chapter 5. Result 5.11.1 Testing Data Access The generic repository only have to be tested once, it doesn’t have to change when new entities are added. What remains is to test the specifications. The specification in listing 5.6 is only satisfied by apartments (objects) that are active. In this case an apartment is active if its isInActive attribute is null or false. There are three possible states for apartments: 1. isInActive = null should satisfy the specification. 2. isInActive = false should satisfy the specification. 3. isInActive = true should not satisfy the specification. Each state can now be tested in a unit test. The only dependency that specification has is on POCO entities. Recall from section 5.3 that POCO entities have no dependencies at all. Listing 5.6: Specification for an active apartment. public class O b j e c t I s A c t i v e S p e c i f i c a t i o n : SpecificationBase < PumaPOCO . Object > { public O b j e c t I s A c t i v e S p e c i f i c a t i o n () { predicate = obj = > ! obj . isInActive . HasValue || obj . isInActive . Value ←== false ; } } Listing 5.7: Unit testing the Specification for an active apartment. [ TestMethod () ] public void ←O b j e c t I s A c t i v e S p e c i f i c a t i o n _ s h o u l d _ m a t c h _ o b j e c t _ w i t h _ i s I n A c t i v e _ n u l l () { PumaPOCO . Object obj = new PumaPOCO . Object () { isInActive = null }; O b j e c t I s A c t i v e S p e c i f i c a t i o n target = new O b j e c t I s A c t i v e S p e c i f i c a t i o n () ; bool expected = true ; bool actual = target . IsSatisfiedBy ( obj ) ; Assert . AreEqual ( expected , actual , " Object should satisify specification " ) ; } 5.11. Unit Tests 5.11.2 25 Test Data Because the test cases are so isolated in most cases the amount of test data required for each unit test is very small. Instances of POCO entities are created on the fly in the test method and sent as parameters to the method under test. 5.11.3 Mocking Using the technique in section 5.8 it is possible to replace the real implementation of a dependency with a fake, or mock object. One way of doing this is to implement the same interface and replace the factory to return the mock object. In this case an external library called Moq[8] is used. It is a library that makes it possible to easily implement an interface on the fly. By default each method will return the default value of the return type, for example null for all reference types. Specific methods can then be overrided to return any value. A short example can be seen in listing 5.8. Listing 5.8: A mock implementation of ICalcValueCalculator is created and the IsObject MatchingCalcValue method is overridden to always return true for any input. [ TestMethod () ] public void MyTest () { Mock < ICalcValueCalculator > c a l c V a l u e C a l c u l a t o r M o c k = new Mock < ICalcValueCalculator >() ; c a l c V a l u e C a l c u l a t o r M o c k . Setup ( x = > x . I s O b j e c t M a t c h i n g C a l c V a l u e ( It . IsAny < ICalculationObject >() , It . IsAny < CalcValue >() ) ) . Returns ( true ) ; } } 5.11.4 Example An example of a test method from the project can be seen in listing in 5.11. The test tests the FormulaCalculator method GetFormulaCalculatedPointsForObject which interface can be seen in listing 5.9. The purpose of this class is to take an apartment (ICalculationObject), model and formula and calculate the score for the apartment. Because each class is supposed to have only a single responsibility (section 4) this class only takes the score for each formula alias (A, B, C) and substitutes them into the formula to calculate the final score. The rest of the calculation is performed by another class, through an interface called IModelLayoutCalculator. The method that calculates the points is called GetFormulaCalculatedPointsForObject. The interface can be seen in listing 5.10. The first thing to do in the unit test in listing 5.11 is to set up the test data. Because POCO entities are used they can simply be created on the fly, and only the relevant data has to be initialized. For example the model and object will never be read, so no fields has to be initialized. The formula is initialized to a + 2 × b. The next step is to hard code a return value for the GetFormulaCalculatedPointsForObject method, because the purpose of this test is to test the FormulaCalculator, not any other classes. Using Moq[8] a mock object is created and the method is set up to return the hard coded value. 26 Chapter 5. Result Using the inversion of control factory method the FormulaCalculator is set up to use the mock object instead of the real implementation. Now that everything is set up the actual method that is to be tested can be called, and the returned value should be 1 + 2 × 2 = 5. Listing 5.9: The interface IFormulaCalculator implemented by FormulaCalculator. [ TestMethod () ] public interface I F o r m u l a C a l c u l a t o r { decimal G e t F o r m u l a C a l c u l a t e d P o i n t s F o r O b j e c t ( I C a l c u l a t i o n O b j e c t obj , ←I C a l c u l a t i o n M o d e l model , Formula formula ) ; } Listing 5.10: An excerpt from the interface IModelLayoutCalculator implemented by ModelLayoutCalculator. [ TestMethod () ] public interface I M o d e l L a y o u t C a l c u l a t o r { Dictionary < string , decimal > G e t P o i n t s F o r R o o t M o d e l L a y o u t s (←I C a l c u l a t i o n O b j e c t obj , I C a l c u l a t i o n M o d e l model ) ; ... } 5.11. Unit Tests 27 Listing 5.11: A test method for the formula calculator. [ TestMethod () ] public void S h o u l d _ c a l c u l a t e _ t h e _ p o i n t s _ b a s e s _ o n _ t h e _ f o r m u l a () { // Setup test data . I C a l c u l a t i o n M o d e l model = new C al c ul a ti o nM od e l () ; I C a l c u l a t i o n O b j e c t obj = new C a l c u l a t i o n O b j e c t () ; Formula formula = new Formula () { Formula1 = " a + 2 * b " }; // Instead of the model layout calculator calculating the points the ←result is hard coded . Dictionary < string , decimal > points = new Dictionary < string , decimal >() ; points . Add ( " a " , 1) ; points . Add ( " b " , 2) ; // Create a mock of the model layout calculator that returns the hard ←coded points . Mock < IModelLayoutCalculator > m o c k M o d e l L a y o u t C a l c u l a t o r = new Mock <←IModelLayoutCalculator >() ; m o c k M o d e l L a y o u t C a l c u l a t o r . Setup ( m = > m . G e t P o i n t s F o r R o o t M o d e l L a y o u t s ( It . IsAny < ICalculationObject >() , It . IsAny < ICalculationModel >() ) ) . Returns ( points ) ; // Use the inversion of control factory to make the formula calculator ←use the mock object instead of the real object . F o r m u l a C a l c u l a t o r target = new F o r m u l a C a l c u l a t o r () ; target . M o d e l L a y o u t C a l c u l a t o r F a c t o r y = () = > m o c k M o d e l L a y o u t C a l c u l a t o r .←Object ; decimal expected = 5; // Make the call to the method under testing . decimal actual = target . G e t F o r m u l a C a l c u l a t e d P o i n t s F o r O b j e c t ( obj , model , ←formula ) ; // Assert that the returned value is the expected one . Assert . AreEqual ( expected , actual , " The formula calculated points are ←incorrect . " ) ; } Almost all unit test are based on the layout of the test in listing 5.11. Sometimes not all steps are necessary, for example if a class has no dependencies. The following are the steps used: 1. Create test data. 2. Create mock object that return test data. 3. Replace the real dependencies with mock objects. 4. Call the method that is to be tested. 5. Assert that the return value is the expected value. 28 Chapter 5. Result Chapter 6 Performance The purpose of the performance measurement is to determine how well the application performs when the amount of data is scaled up. The different loading methods in section 5.9 are compared. 6.1 Test Data The test data sets are based on a customer database with 8723 apartments. The apartments were duplicated or removed to create differently sized databases. The number of apartments in each database are 100, 200, 500, 1000, 2000, 5000, 10000, 20000, 50000, 100000 and 200000. The numbers were chosen based on the size of existing customers databases and expected size of future customers. 6.2 Test Application A test application was created to test the performance. The time to perform the calculation, including loading all data, and store the result in memory was measured separately from the time to save the result to the database. The data persistence is the same for each test and therefore not interesting. However, to be able to compare the new calculator to the legacy one the save time has to be measured as well. The test application measures the number of apartments that were calculated each second. This is used to see if the calculators performance change over time. The memory usage was also measured. A separate thread was used that wakes up every seconds and polls the garbage collector for the current amount of memory allocated by the garbage collector. Before each poll the garbage collector releases all unreferenced memory. 6.3 Execution Each implementation is run ten times for each database. The first execution takes longer and is discarded. This is because Entity Framework performs some initialization the first time it is invoked. The mean value of the remaining nine values are used as the result. 29 30 Chapter 6. Performance 6.4 Result 6.4.1 Calculation time The average number of calculated apartments per second is shown in figure 6.1. The function import, inline query and stored procedure performs equally with a peak performance at about 10000 apartments. This means that the calculation is not completely linear and for larger number of apartments the performance rapidly decreases. The reason for this is that Entity Framework performs some automatic linking of related entities that is not executed in constant time. The LINQ and Specification methods also performs equally but compared to the other methods the performance is awful. They were also unable to calculate more than 50000 apartments so no result is recorded for bigger data sets. 1000 Calculations per second (n/s) 900 800 700 600 Function Import Inline Query LINQ Specification Stored Procedure 500 400 300 200 100 0 1 10 100 1000 10000 Apartments (n) 100000 1000000 Figure 6.1: Comparison between the different data loading methods. 6.4.2 Memory Usage The memory usage for each methods for different number of calculated apartments can be seen in figure 6.2. The specification method is the most memory intensive with a peak memory usage of 361 MiB calculating 50000 apartments. The LINQ method uses almost 200 MiB for the same calculation and the rest uses only about 20 MiB. Even for 200000 apartments the memory usage is only 50 MiB. 6.4. Result 31 512 Peak memory (MiB) 256 128 64 Function Import Inline Query LINQ Specification Stored Procedure 32 16 8 4 2 1 10 100 1000 10000 Apartments (n) 100000 1000000 Figure 6.2: Comparison between the memory usage of the different data loading methods. 6.4.3 Persistence Early versions used the data persistence feature of Entity Framework to save the result of the calculation to the database. An early test run showed that for large amounts of data the time to save the result was greater then the actual calculation. The result of the test run can be seen in figure 6.3. Saving the result of 200000 apartments took 35 minutes. The memory usage was also extremely high, figure 6.4 shows a peak memory usage of 963 MiB. The persistence step starts at about 1000 seconds and continues until the end of execution. 32 Chapter 6. Performance 10000 Save time (s) 1000 100 Calculation Time Save Time 10 1 1 10 100 1000 10000 Apartments (n) 100000 1000000 Figure 6.3: Performance of using the function import method for calculation and the Entity Framework persistence feature to save the result. Memory Usage (MiB) 1200 1000 800 600 Function Import 400 200 0 0 500 1000 1500 Elapsed time (s) 2000 2500 Figure 6.4: The memory usage when saving using Entity Framework. The final program uses the SqlBulkCopy[13] function and saving the same amount of data takes only 14 seconds with a memory usage of only a few kibibytes. This method is not 6.4. Result 33 as flexible however and the records persisted to the database are not automatically updated on the client side, but have to be loaded again manually. 6.4.4 Legacy Calculator A comparison was made with the old calculator and one of the most efficient methods, function import. This comparison includes the time to persist the result to the database. The result can be seen in figure 6.5. The old calculator calculates only five apartments per second while the new one using function import and the SqlBulkCopy function has a peak of 762 apartments per second. 800 Calculations per second (n/s) 700 600 500 400 Function Import Old calculator 300 200 100 0 1 10 100 1000 Apartments (n) 10000 Figure 6.5: Comparison between the function import method and the old calculator. 34 Chapter 6. Performance Chapter 7 Conclusions Because of lack of time the external supervisor did not have time to create a formal specification. This meant it took some time to actually figure out what the thesis was all about. Despite the slow start the work went on smoothly and the project was finished only one week behind schedule. The resulting application is fully functional and it performs the same task as the old program but over a hundred times faster. A big improvement in performance was expected, but the result still exceeded the expectations. The module has over 200 unit tests and only time can tell if it is easily maintained, but it will have a greater chance than the legacy application. The main goal of the thesis was to find a method to incorporate unit testing into the development cycle. It turned out that the main problem was not to write test cases, it was to write code that is easy to test. By abstracting away the database access and adhering to the rules of observability, isolation and single responsibility principle writing unit test will be a lot more feasible in the future. Because of the unit tests some of the bugs introduced when adding new features to the program will be avoided. Smaller and less coupled classes will also make it possible to reuse tried and tested classes, avoiding the need to modify classes and risking introducing new bugs. The thing that is missing is integration tests that make sure that the module as a whole is still working after modifications has been carried out on the module. Another main topic was how to test data access code. This turned out to be the hardest part where several approaches had to be completely abandoned. It was either too much effort to write the tests or the tests were useless. The final solution of using specifications is a good compromise and, at least in theory, the whole concept has a lot of potential. The evaluation of Entity Framework 4.0 showed that almost all code can be automatically generated from the database, minimizing the effort needed to bring the database into object oriented code. The performance however is awful for large sets of data. Thankfully it is possible to optimize the bottlenecks by replacing them with stored procedure. It would have been interesting to compare Entity Framework with more mature ORM frameworks, most notably NHibernate[17]. The unit tests created are very useful, but there is also a need for integration tests to test the interactions of units. A big challenge here is to maintain test data that can be updated together with the application. This is another topic that would be interesting to explore. 35 36 7.1 Chapter 7. Conclusions Limitations The main limitation of the module is that is not yet integrated into the graphic user interface of the rest of the application. More issues will probably have to be considered when the module is integrated with user input. There is a feature to select only a subset of the apartments to be used in the calculation, but its performance does not compare to loading all apartments at once. A better solution has to be found in creating this subset. 7.2 Future Work A lot of things like maintainability cannot be evaluated before the module starts to expand. There is also not known how much an effort is required to maintain the code, keeping all test cases up to date. Because unit tests only test each unit in isolation the test suite will not detect errors that occur when units are interacting. It would be possible to create a suite of integration tests that test the service layer, because it has a well defined interface. These tests requires another database with test data that has to be maintained when the application changes. Chapter 8 Acknowledgements I would like to thank TRIMMA for the opportunity of doing this project and my external supervisor Mattias Blom and the other employees at TRIMMA for their feedback. A thanks also to my internal supervisor at Umeå University, Jan-Erik Moström. 37 38 Chapter 8. Acknowledgements References [1] Scott Allen. Testability and Entity Framework 4.0. http://msdn.microsoft.com/enus/library/ff714955.aspx (visited 2012-05-21). Specification Pattern, Entity Framework & LINQ. [2] Will Beattie. http://blog.willbeattie.net/2011/02/specification-pattern-entity-framework.html (visited 2012-06-01). [3] SABO Sveriges Allmännyttiga Bostadsföretag. Sätt rätt hyra, handledning i systemematisk hyressättning, 2010. [4] Martin J. Fowler. ObjectMother. http://martinfowler.com/bliki/ObjectMother.html (visited 2012-05-22). [5] Martin J. Fowler. Patterns of Enterprise Application Architecture. Addison-Wesley Professional, 2002. [6] Edward Hieatt and Rob Mee. Repository. http://martinfowler.com/eaaCatalog/repository.html (visited 2012-05-22). [7] Hyressättningsutredningen. Sou 2004:91 reformerad hyressättning. Socialdepartementet, 09 2004. [8] Clarius Consulting Labs. Moq. http://code.google.com/p/moq/ (visited 2012-06-05). [9] Julia Lerman. Agile Entity Framework 4 Repository. http://thedatafarm.com/blog/dataaccess/agile-entity-framework-4-repository-part-1-model-and-poco-classes/ (visited 201205-23). [10] Julia Lerman. Programming Entity Framework. O’Reilly Media, 2009. [11] Robert C. Martin. The single responsibility principle. Principles of Object Oriented Design, 2002. [12] Microsoft. Code Generation and T4 Text Templates. http://msdn.microsoft.com/enus/library/bb126445.aspx (visited 2012-07-30). SqlBulkCopy Class. http://msdn.microsoft.com/en[13] Microsoft. us/library/system.data.sqlclient.sqlbulkcopy.aspx (visited 2012-06-25). [14] Microsoft. The ADO.NET Entity Framework Overview. http://msdn.microsoft.com/enus/library/aa697427(v=vs.80).aspx (visited 2012-06-07). [15] Microsoft. Unit testing framework. http://msdn.microsoft.com/enus/library/ms243147(v=vs.80).aspx (visited 2012-08-01). 39 40 REFERENCES [16] MyGeneration. The dOOdads .NET Architecture. http://www.mygenerationsoftware.com/portal/dOOdads/Overview/tabid/63/Default.aspx (visited 2012-06-07). [17] NHibernate. Nhibernate. http://nhforge.org/Default.aspx (visited 2012-08-01). [18] Stephanie Punke Peter Schuh. Objectmother - easing test object creation in xp. XP Universe, 2003. [19] R. Venkat Rajendran. White paper on unit testing. Deccanet Designs Ltd., 2002. [20] Philip Craig Tim Mackinnon, Steve Freeman. Endo-testing: Unit testing with mock objects. XP eXamined, 2000.
© Copyright 2024