Quantity of test must come with quality

For those that are familiar with TDD, you should be aware of what code coverage is. For those that don’t, do check out the paper written by Brian Marick “How to Misuse Code Coverage”!

From my perspective, code coverage measures certain quantity and not the quality of the test on the code. Quantity figure defined can be easily achieved without any quality. Imagine writing test that just assert whether an object is null will put those line of codes or sequence points visited. However, does this test really visit the complexity involved? If you have one test to cover a method and if you have five tests to cover the same method, the coverage is still the same. These five tests might be written to provide a more exhaustive test (Phil Haack has provided a good overview about the row test).

How many times are you thrown a code coverage figure to be achieved? I believe the easiest figure to be defined is 100%. But will a project be able to meet this figure realistically, given the resources? How many have written test for the sake of achieving this code coverage figure but without any quality. Probably is important for people who determine this figure to be achieved to make some thoughtful analysis of what is more important. Having read a couple of times that the 100% is unrealistic in many projects, so what make a good and realistic figure? How many have been given a figure of 80%? Was this figure pluck from the air? I often don't see how this figure is derived. To me more importantly, certain guidelines need to be defined what need to be achieved from the test suites rather that just a quantity figure.

The guidelines should define the quality of the test, what need to be tested and what is not (this fall outside the code coverage figure). Most often, tests need to cover the core business domain logic, to prove that they not only pass but all the complexity in business logic defined are tested. Does a facade or delegate without any logic need to have any test? My answer should be most likely NO. Why? Usually a façade or delegate intend is to expose certain methods, so how are you going to test this intend? Accessibility concern can be easily detected when a project is complied.

Therefore, do have a good understanding of what you trying to achieve instead of letting tools available to determine what you can achieve without any significant purpose. Code coverage tools will be useful to provide an overview on the code coverage for the project, but the quality of code and test suite most likely can only be achieved thru a set of standard and guidelines defined with code review. Of course, other tools such as NDepend which provide different types of code analysis are also available.

Version control for database?

Having a database under version control have it own advantages and disadvantages. K.Scott Allen recently has written a five part series on database version control. I think his article provide a very good background on getting the database under version control. Jeff Atwood also highlighted that the database are very often neglected in most project. To my understanding these articles seems to have assume that all database should be kept under version control. I think the first question should be whether version control for a database is required? The following are a few questions to ask yourself before deciding on whether you should have your database kept under version control:

1. How many people have the right to make changes to the database?
2. Is there any problem with the development and testing with a constant change made to the database?
3. How many environments do you have from development to production?
4. How is the deployment for the changes to the other environment carried out?
5. Have scripts not meant to be deployed, been deployed during deployment?
6. Any review done to the changes made to the database?
   

Application with big and multiple databases usually have more that one single person having the right to change any part of the database and this can be worrisome, as things can get out of hand easily. Version control will be able to help in keeping track what the changes are made over time. This is very useful for everyone involve in the project, from the developer to the DBA as everyone will be able to track the changes made. By using a shared database, how often and badly does it affects other developers working on the same project? If the impact is unbearable or consuming too much time and effort, then probably keeping the development database separately might be good. However, there is trade off as keeping database in sync is not going to be an easy task without proper process and tool.

Having too many environments such as development, multiple testing environment and production is going to make deployment an uphill task. With each environment in the different phase of a project will make things even more complicated. Therefore, with version control of the database, the different version or phase at the point of time can be easily identified. This will perhaps make the change management easier to manage and prevent wrong version from been release to production. If you find yourself in the mess described, my advice is to go ahead and get your database under version control.

Imagine with a click on the checked in log, you can easily track all the changes done to a database. This is the advantages that not only allows you to just track changes, but it also allow you to review the changes done and any wrong doing. From experience, the process of keeping a database under version control is complicated and can be tedious. If the process is not well thought enough and people not having a clear picture of the version control, result will be the above issue coming back haunting on you again. Therefore, the initially phase in adapting to new process can be difficult, but over the long run the result will obvious.

Filling up the gap on becoming a better developer

Reading the prefer design skills post written by Martin Fowler recently, I begin to look at the post from the perspective of an employee and a developer rather than looking from the perspective of an employer. As a programmer myself and agreeing with most of the reason highlighted as the preference, I believe this post can be used as one of the route to becoming a better programmer or developer.

Has design skill been neglected? With so many posts out there, providing valuable guidance on how to improve oneself to become a better developer, still the design skill is not often mentioned anywhere. So, the prefer design skills post probably helped to fill up one of the gap on becoming a better developer. The following are some excellent view point on becoming a better developer through technical and non-technical ways:

• Becoming a Better Developer by Software by Rob

• 10 Developer For The Price Of One by hacked

Other than looking at the prefer design skill post from a different perspective, I believe this post also open up the perspective of an employer on hiring a developer to anyone. Therefore, this is probably one of the criteria that your new employer will be looking for in you. In my opinion, the development world is so dynamic and fast-paced with new language, platform, hardware, software and etc been introduced now and then. As such, the need to be adaptable to change and keeping oneself updated with all these changes is as important, else a developer can become obsolete with the language and platform he or she is most comfortable with. Having broad skill and knowledge, a developer will be able to look at the different pro and cons of different platform, software and even hardware can provide. With this, a better choice can be made and instead of constraining to the limitation of what a single platform cannot provide.

Nhibernate many-to-one (M:1) mapping

While working on a project recently, I started to analyze all the query generated by the Nhibernate for the different mapping available. Playing with the fetching strategy and lazy loading option, I will be able to see how the different queries are form. Interestingly, I realized that the M:1 mapping does not have a lazy loading option, and decided to further investigate more on this mapping.

M:1 mapping is use for object reference, the same idea as the M:1 association in the relational model. To test and see the query generated by the Nhibernate, I decided to load a class with M:1 mapping. To my surprise, the generated query pulled about 80% of the tables found in my database. Going back to the class, the class that I am trying to load have two many-to-one mapping and the referenced class also have other M:1 mapping within the class itself and the reference traverse for about four times.

With this, I started to reflect if there are something wrong with my class design and also wondering why the M:1 mapping does not support the lazy loading option? Not too sure but probably the idea of the many-to-one mapping reference object in terms of records in the database will always be smaller than the number of records for the referencing object. But imagine if the targeted growth for the referenced object is to peak to about a million records in the database and the referencing objects is about 10 million. The penalty of loading both the referencing and referenced object will be pretty obvious without the lazy loading option.

Apart from the lazy loading option, the default fetching strategy seems to be different from what is stated in the Nhibernate document for the M:1 mapping. Without specifying any fetching strategy for the M:1 mapping, the fetching strategy use is "Join". Only when it is explicitly specific to "Select", the select strategy is use. Therefore, I urged anyone using the Nhibernate with certain performance consideration in mind should start looking at the query generated by Nhibernate.

To workaround this issue, for all M:1 mapping without much targeted growth in records, the mapping will be maintain as the performance might be minimal. For mapping with a high targeted growth and with the referenced object information seldom used, the mapping relationship should be removed and only loaded when necessary through the referenced object. However, that means the logic of what to load have to be manually managed and it will be similar to the N+1 problem found with lazy loading. Ayende Rahien have some good explanation and the workaround for this N+1 problem.

Discussion with Jimmy Nilsson

Last week, my company has engaged Jimmy Nilsson to provide a consultation to a new project that we are working on. During this period, my colleagues and I had an intense discussion with him on topics like Domain Driven Design (DDD) and Test Driven Design (TDD). The discussion has opened up a lot of approaches, concepts and ideas to our new project. New to these topics and having read a few books on them, this discussion really provide a better picture of those missing part found in the books and clear up some of the assumption we have made.

Where is the most complex part of an application? Usually, the domain layer of the application is the most complex part as it contains the different complexity found in different domain. Therefore, design and maintenance of the domain complexity can be one of the greatest challenges in a big project. The book Domain Driven Design Tackling Complexity in the Heart of Software by Eric Evans provides a good idea of how this challenge can be managed and overcome. Together with TDD and Agile software development approach, the book Applying Domain Driven Design and Patterns: With Example in C# and .NET by Jimmy Nilsson provide another approach of applying the DDD with.

During the discussion, Jimmy has given another definition of his on the TDD, which the focus is not only on testing, but also to be used as a driving tool for the domain design. The idea of this approach is to think and let the design evolve as the codes are written. As a team using this approach, he or she should not be afraid of changes. In software development, what is not changing is the amount of changes that we are seeing throughout the development lifecycle. As for how good the DDD and the Agile approach will turn out to be, I will come back again to review it as the project mature.

My First Post

About me…

My New Year resolution was to create a personal blog to share my greatest interest and to give some reflection about what I have done by writing them down. Well, this is not my first time writing a post. I have written a few posts with a blog shared with a co-worker, but my co-worker has left the company I am working in for good. Anyway that blog is only for techie stuff.

Not for any selfish reason, I will continue to post techie stuff on that blog if this co-worker of mine is still interested in keeping the blog active. Of course, this blog will be more than techie stuff. I am hoping to write and post some photo of one of my long time interest – Rock Climbing.

I reside in Singapore and work as a software developer. Working as a developer, I need to constantly carry out research and read about the vast and different technologies, tools, approaches and ideas available in this fast paced sector. The dynamic nature of IT world resulted with a lot different thought and opinion from different people. Therefore, I hope to share some of my thought and opinion here.