As I told you before, I want to separate my application in 3 parts. I know that architecture could be discussed but I would make this point clear, it should be “re-factored”. Anyway, for the moment, I think it is enough flexible for what I want to do NOW.

Here is a reminder of my layers:

• The Web application which will be the view of my application.

• The controller with all my business logic embedded in a library Service.

• The model library which will contain my models, my data access (repository) and all my filter static classes.

To improve my explanations, I hand draw a little pseudo UML diagram :

What I want it is to keep as much as I can the “Soc” (separation of concern). My service should make what a service should do and if I want to change my repository with a Oracle one, I could change it only by modifying the instantiation of my service (with DI for the future). I want to keep that “philosophy” all along the development but philosophy is not obligation.

In the same way, you’ve certainly noticed that I often return an IQueryable for my “get” method (see listing 1). I know this should be better to return a List type cause it is a more “standard” and you do not have to use the Linq library. Nevertheless I think I will keep it. I do not want to call to often the .IEnumerable function and also it will be easier to use my filter classes.

As the only developer for this application, I assume my choices. If you have remarks about this, please leave a comment.

Listing 1 : Example of the getPages method who retreive all the page from my db

public IQueryable<Page> getPages()
{

return from p in _db.Posts
where p.Type == "Page"
let lp = getLocalizedPages(p.PostID)
select new Page
{
PageID = p.PostID,
Author = p.Author,
Date = p.Date,
PageLozalized = new LazyList<PageLocalized>(lp),
ModifiedDate = p.ModifiedDate,
Password = p.Password ?? string.Empty,
Permalink = p.Permalink,
Status = p.PostStatusID,
Version = p.RevisionOf

};
}

private IQueryable<PageLocalized> getLocalizedPages(int postID)
{
return from lp in _db.PostCultureDetails
where lp.PostID == postID
select new PageLocalized()
{
Description = lp.Excerpt,
Text = lp.Text,
Title = lp.Title,
LanguageCode = (from culture in _db.Cultures
where culture.CultureID == lp.CultureID
select culture.LanguageCode).SingleOrDefault()

};

}

Why I did not use Entity framework ? I hate when the framework decide for me which object I should use. Also, the time I would spend to make it work as I want is doubtless longer than the time I wrote my custom Linq to Sql Class. Entity framework could be great for simple application but for an application who will grow in the future (as I expect Kiwi will do) I do not think it’s a good choice.

Why I did not use NHibernate ? I could have chosen NHibernate, but I absolutely wanted to play with Linq. Also, maybe in the future I could make the data access with it and compare what’s better for my application. Anyway, this is not the time to do this.

If you have other questions like this, please, do not hesitate.

And now the service :

As I mentioned, my data access is almost finished (for the moment). I am going to create the services I need for my application. Evidently, always in a TDD approach.

Kiwi Part 4 was bullshit :

Maybe it was but the aim of that post was to show you how to start with TDD. And I know that I was going in front of a wall. Indeed, I had an empty db and the post object was the most connected object. As you know in TDD, you write a test, you write some code. I realized that I should have written a lot (before creating the “SaveFunction” for it). I needed the category object, the comment object,… Thus, I begin to create a save function for the category object (alway with a tdd style).

Create the test :

//Spike Test !!!
[TestMethod]
public void SqlPostRepositoryTest_can_add_category()
{

Category category = new Category();
category.CreatedDate = DateTime.Now;
category.CategoryParentID = 0;
var categoryEn = new CategoryLocalized() {Description = "This is a test", Value = "Software Development", LangageCode = "EN"};
var categoryFR = new CategoryLocalized() { Description = "Ceci est un test", Value = "Développement Logiciel", LangageCode = "FR" };

var list = new LazyList<CategoryLocalized>();
list.Add(categoryEn);
list.Add(categoryFR);

category.LocalizedCategory = list;

_repository.Save(category);

Assert.IsNotNull(category);

}

And after the function I need :

//save or add a category

public void Save (Category category)
{
var dbCategory = (from c in _db.Categories
where c.CategoryID == category.CategoryID
select c).SingleOrDefault();
if(dbCategory == null)
{
dbCategory = new SqlRepository.Category();
dbCategory.CreatedDate = DateTime.Now;
dbCategory.ParentID = category.CategoryParentID;
//commit the change to have the id and insert the culture
_db.Categories.InsertOnSubmit(dbCategory);
_db.SubmitChanges();

//foreach culture we have in the objec we add it in the table CategoryCultureDetail
foreach (CategoryLocalized item in category.LocalizedCategory)
{
var dbitem = new CategoryCultureDetail();
//some Object to DB
dbitem.CategoryID = dbCategory.CategoryID;
dbitem.Description = item.Description;
dbitem.Value = item.Value;
dbitem.CultureID =
(from culture in _db.Cultures
where culture.LanguageCode == item.LangageCode
select culture.CultureID).SingleOrDefault();
dbCategory.CategoryCultureDetails.Add(dbitem);
_db.SubmitChanges();
}

}
else
{

foreach (CategoryLocalized item in category.LocalizedCategory)
{
var thisCategoryLocalized = (from cn in _db.CategoryCultureDetails
where cn.CategoryID == category.CategoryID
where cn.CultureID ==   (from culture in _db.Cultures
where culture.LanguageCode == item.LangageCode
select culture.CultureID).SingleOrDefault()
select cn).SingleOrDefault();
thisCategoryLocalized.Description = item.Description;
thisCategoryLocalized.Value = item.Value;
_db.CategoryCultureDetails.InsertOnSubmit(thisCategoryLocalized);
_db.SubmitChanges();

}
}
}

Of course, you see the “final” result. To have that, I went by little piece of code. Test, write, build, test, write, build, test …

I also know the test you see above is not a unit test, it is more an integration test or a spike test and it will be deleted or commented in the future.

But the name is test driven design and not “make pure unit test” design.

NOTE : I know I am saying that each time I post but I will try to add the source code in my codeplex project this afternoon.

UPDATE  : I put the source on code plex, if you would like to see it : http://dervalp.codeplex.com/

I have some troubles with codeplex, I will check this out tomorrow cause I am a bit tired today.

Bookmark It

Hide Sites

Indeed, maybe, you do not need it. Indeed, you were doing without it but if you are a developer, you should be open to new technologies, curious and maybe you should test it before saying that you do not need it.

Main bugs come from stupid errors. If you use TDD, a lot of this (syntax, typo, omission) error will emerge quickly.

To make your code testable you have to understand all the methods and objects you use. I think it is the main reason why some developers fear about TDD cause if you want to simulate your httpcontext for example, you have to understand how a httpcontext works.  Also, to do that, you have to “mock”, good tools exist to help developers to setup fake context but It cost you time.

Is it worth? I would say yes. In the end of the process,  you can be self-confident with your code and you can explain to everyone what you are doing without gray area. Moreover, if you change something in your code, you should be able to know if there are side effects or not. You will execute all your tests and if all your tests pass, you are safe. If not, you can immediately know where you have to change.

The other great thing with TDD is the iterative way. You create a test, it fails, you write some code, you execute the test, if it is ok, you write a new test,… Like this you feel less overwhelmed by your project.

The definition from Wikipedia :

Test-driven development (TDD) is a software development technique that uses short development iterations based on pre-written test cases that define desired improvements or new functions. Each iteration produces code necessary to pass that iteration’s tests. Finally, the programmer or team refactors the code to accommodate changes. A key TDD concept is that preparing tests before coding facilitates rapid feedback changes. Note that test-driven development is a software design method, not merely a method of testing.

“The act of writing a unit test is more an act of design than of verification. It is also more an act of documentation than of verification. The act of writing a unit test closes a remarkable number of feedback loops, the least of which is the one pertaining to verification of function”. Bob Martin

I guess it is what a developer should understand. Writing a test is not only test but it a act of design.

For example, we have an application who manage flights in the Airport X. And the client want to see all the flight details who land between 3 PM and 4 PM in that Airport. The questions are : What do you need ? Where do I have to query the data ? Also, maybe you have to deal with 5 or 6 web services.  How are you going to test this function without unit tests ?  Are you going to create a gridview to see the results and go in debug mode ? It is going to be a nightmare. But if you go step by step by using TDD, I am sure it will be easier cause when you will write your tests, you will ask the right questions and you will better understand the domain you are dealing with. It is, “Think before programming”.

In conclusion, I am not going to explain how TDD is working. I know some websites explain that better than me. I will give you some links that I’ve found usefull during my learning process.  Also, maybe my opinion on TDD will change, in that case, I will update this post. As usual, feeback is welcome.

Related Links :

Wikipedia

AgileData

Rob Connery

Phil Haack

NOTE : For my unit tests, I am using Visual Studio 2008 SP1. I used Nunit in the past but, for me, VS makes a good job with unit test so I’ve switched. If you have feedback in that topic, you’re welcome.

NOTE2 : TDD without Mocking is not TDD, I will write a post about that in the future.

Bookmark It

Hide Sites

First of all, Scrum is just a methodology and not a magic word that would erase all the problems during your development lifecycle. Rather than invent a new definition of Scrum, look at the wikipedia definition:

Scrum is an iterative incremental process of software development commonly used with agile software development.

The significant word here is iterative.

I have sometimes lack of motivation, sure, you sometimes have too, so let’s begin with a too classic Developper Story :

Your project manager arrive with a really really really important project from the business with a f***** high top priority. The release date is tomorrow and you have half a post-it as specifications.

After crying, screaming, “black outing”, think about a resignation, you will begin to feel overwhelmed by the whole project.

At this point, take a break and learn Scrum.

Scrum splits an entire project in little comprehensive action. It helps us to focus on what is important now and not what you will do in one week. Sure, do not forget to think before programming but do not believe the user specification as the holy grail cause there is 95 % that it will change.

Overview from Mountaingoatsoftware

Let’s play : the roles in Scrum

Two groups : the pigs and the chickens, based on a joke.

Here is the joke :

A pig and a chicken are walking down a road. The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?” The pig looks back at the chicken and says, “Good idea, what do you want to call it?” The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs’?” “I don’t think so,” says the pig, “I’d be committed, but you’d only be involved.”

From wikipedia :  The “pigs” are committed to building software regularly and frequently, while everyone else is a “chicken” – interested in the project but really indifferent because if it fails they’re not the pigs – that is, they weren’t the ones that committed to doing it. The needs, desires, ideas and influences of the chicken roles are taken into account, but are not in any way allowed to affect, distort or get in the way of the actual Scrum project.

PO (product owner) :  The Product Owner represents the voice of the customer. He/she ensures that the Scrum Team works with the “right things” from a business perspective. The Product Owner writes user stories, prioritizes them and then places them in the product backlog

Generally, it is you manager or you project leader. The point here is to convinced you manager to play that game. Explain him that Scrum will help to have a better view on what the team is doing. Do not forget to show him the product backlog and the sprint backlog with the little graphics (we will see that later). I am sure he will be happy. If he is still not convinced, try a strike or organize a strategy with your colleagues to find out how you could transform you boss as a product owner. There are plenty of arguments on the net and in your head.

ScrumMaster (or Facilitator) :

Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules. A key part of the ScrumMaster’s role is to protect the team and keep them focused on the tasks in hand.

He acts like a shield for the team. Avoid the word “self-organizing” near you boss, he will be scared to lose the control. Another tip, use the word Facilitator instead of Scrummaster, the scrum master is not a manager or a leader so avoid the full of meaning word “master”. If you want, you can change your facilitator at the end of the sprint. It brings fresh air for the facilitator himselft and the developer who will take the place for a sprint. Sure, you facilitator can act as a developer or you have a strange team (Yeah, I know It happens).

The Team
The team has the responsibility to deliver the product. A team is typically made up of 5–9 people with cross-functional skills who do the actual work (designer, developer, tester, technical communicator, etc.).

I know, sometimes you are only 3 or 4. I do not know if there is a minimum number. I used to develop in a 3 people team with SCRUM and I can say that It is make sense.

Try to find a funny name for you team, it can bring fun and jokes…

The Team, the ScrumMaster and the PO are pigs.

The User :

The software is being built for someone

Stakeholders (customers, vendors) :

These are the people who enable the project and for whom the project will produce the agreed-upon benefit[s], which justify its production. They are only directly involved in the process during the sprint reviews.

Sometimes Stakeholders are Users, prepare to have a lot of changes in your specifications.

Managers :

People who will set up the environment for the product development organizations.

The important thing : communication

- The Daily Scrum

Each morning (8:00 am for us), the scrumaster (see below) organize a little meeting (about 15 minutes) next the cofee machine and ask three questions to all the team members:

• What did you do yesterday ?

• What will you do today?

• Are there any impediments in your way?

The daily scrum is not a place for debating technical problems and personal life, it is just a quick overview which helps everyone to know what you are doing, what you finished and what you will do.  You have to answer quickly like “I need some help for …” or “I am strugling with …” At the end of the meeting, if the SCRUM master cannot help you directly, he will take the point and decide who can help you or what you have to do.

- Sprint Planning Meeting (PO + ScrumMaster + Team + others significant manager or custormers)

At the beginning of the sprint cycle (every 15–30 days)

The Sprint Planning Meeting is attended by the Product Owner, Scrum Master, the entire Scrum Team, and any interested and appropriate management or customer representatives. During that meeting, you define which tasks will move from the product backlog to the sprint back log. Team members ask questions to know more about specifications and together you define the priority of the tasks. The PO and the ScrumMaster define the goals for the sprint. After the sprint planning meeting, the team discuss if the goals are realistic and negotiate with the PO if there is some change to do.

Please, PO and ScrumMaster, involve your team in the sprint planning meeting, it is very important that the team feels the issues and the context of the projects they are working on.

- Sprint Review Meeting (PO + ScrumMaster + Team + others significant manager or custormers)

During that meeting you will discuss on what is completed and not completed. The limit of time is 4 hours. I encourage the team to make a demo of the new features. It is more visual than a powerpoint. The most important for the team is that the general aims are achieved. If not, it is normal in the beginning cause you need more experience to evaluate correctly the sprint backlog.

- Sprint Retrospective (PO + ScrumMaster + Team)

Discuss on what it works and did not work.  Two main questions during that meeting : What went well during the sprint? What could be improved in the next sprint? Do not hesitate to improve you process.

The artifacts :

The product backlog :

From Mountain Goat Software : The Product Backlog is the master list of all functionality desired in the product. When a project is initiated there is no comprehensive, time-consuming effort to write down all foreseeable tasks or requirements. Typically, a project writes down everything obvious, which is almost always more than enough for a first sprint. The Product Backlog is then allowed to grow and change as more is learned about the product and its customers.

Here is the example of a product backlog : simpleproductbacklog

The Sprint backlog (wikipedia):

This is a greatly detailed document containing information about how the team is going to implement the features for the upcoming sprint. Features are broken down into tasks; as a best practice tasks are normally estimated between four and 16 hours of work. With this level of detail the whole team understands exactly what to do, and anyone can potentially pick a task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills. The sprint backlog is property of the Team. Estimations are set by the Team. Often an according Task Board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”.

Example of a sprint backlog template_sprint_backlog

You can find others sprint backlog and product backlog after a quick search on google…

Conclusion

Like I said before, Scrum is not magic and does not resolve lack of communication, programming errors and environment difficulties. It is just a methodology. I choose Scrum because you do not need 100 hours to understand it and to setting up the environment. You only need your team and some post-it. Managers and customers can easily understand how it works and this is not necessary the case in an IT department. Scrum helps also to avoid an overwhelmed feeling and brings democracy in a team (which is a good thing in my point of view). This is the team who is responsible and not a particular member. It brings also cohesion and team spirit.  I advise you to try it and see if it can fit to your team.

I hope I give you a good overview.

If you have questions, do not hesitate to ask me by comments.

Bookmark It

Hide Sites