TheCodedWorld

Ok, so let's do a quick review of Part II, chapters 6 to 8, of Professional Test-Driven Development with C#. Well, I get it. I think. It is hard to write an entire book on the topic of TDD. Part II is labeled "Putting basics into action" and here the author describes, quite detailed, how he usually works. But unfortunately only a small part of it actually covers writing code. Instead a lot of pages are used to describe how to define the project, how the author and his team defines user stories, the development process they use for Agile software development and then it is framework frenzy again. Frameworks covered is this section includes, NBehave, NHibernate, Fluent NHibernate, and Ninject. The author uses those for writing a total of two unit tests and one integration test. Most of the code describes how to use the frameworks, and very little is actual implementation. So far this book is targeting a person, or team, that wants ideas on how to set up a new C# proje...

There is a lot of resources available online when it comes to TDD. However, I have always found that a good book is better than most online resources. Therefore I borrowed home a book called 'Professional Test-Driven Development with C#' by James Bender and Jeff McWherter. So far I am 5 chapters in to the book (about 1/3) and here is some of my reflections regarding the content: The book provides many code examples, which is positive. There is however at least one code listing that is incorrect (looks like the wrong listing was inserted). The authors put great emphasis on Red-Green-Refactor. That no application code should be written before there is a failing test for it. Still in chapter 5 they write the application code first and then add the tests later - WRONG! A lot of focus is put on the use of frameworks. I understand that you shouldn't re-invent the wheel and that choosing a good test framework, like NUnit, is a good thing to do. However, you should be careful...

I have asked myself this question several times, and searched for answers, without coming up with any clear answer. Therefore I have decided to go hard core TDD for a longer period of time (at least 6 months) to really evaluate the effects. There are several things that I find confusing when it comes to TDD. One example is what actually defines a unit test. What is a "unit" anyway? After reading a bit about it I found a text claiming that the "unit" is "a unit of work", i.e. something quite small. Like converting a string to UPPERCASE or splitting a string into an ['a','r', 'r', 'a', 'y'] of chars. This work is usually performed by a single call to a single method in a single, isolated, class. So, what does it mean that a class is isolated? Does it mean that it doesn't have any dependencies to other classes? NO! In the context of TDD it means that any dependencies are supplied by the test environment, for exa...

Wish to try out some Clojure (you really should, the need to modify existing values in memory is a thing of the past)? Take a look at Clojure Koans , a great way to get some hands on experience using Clojure. I really hope that functional programming, or at least the idea of creating new values instead of altering the location in memory of the current value, grows big. Anyone who has working with multi threaded programs knows that synchronization issues is the biggest source of really nasty bugs today. Limiting these cases to an absolute minimum would make the world of the programmer a lot less painful.

Santa brought me a nice Christmas gift this year, Clojure for the Brave and True . A nice book for learning the basics of Clojure. Since I am not that experienced in functional programming, and especially not in Lisp, it feels like a good thing to take it from the start. For those of you unfamiliar with Clojure, check out https://clojure.org/ and read what Rick Hickey has to say about it. Here is one video to check out, The Value of Values (P.S. I really love how Rich looks like Weird Al)

From time to time, when I learn something new or want to try out a new approach, I restart my "Record Collector" a project. It is a project I use for testing out ideas, and never gets close to a usable product. This time I wanted to try out creating components and setting up the relationship between them using inspiration from Clean Architecture. The Record Collector application keeps track of different records, and needs some sort of record repository. For my simple application is it enough to just have an in-memory list. But I got curious I wanted to see how larger applications, maybe targeting thousands of simultaneous users, tackles this. What I found was the Repository Pattern and CQRS. Here is some resources for any of you who wants to know how repositories or command/query objects can be implemented in large scale applications: The Repository Pattern (msdn) Youtube video by Mosh Hamedani explaining the Repository Pattern Blogpost discussing Repositorios vs ...

Now I have created my first from scratch WPF application using MVVM. I like the concept of separating the view from the model, making it possible to change the view without having to touch the model. The dependencies also goes in the right direction, from the lowest level (the View) having knowledge of the next level (the ViewModel) that finally has knowledge of the highest level (the Model). No dependencies exist in the other direction. Code can be found on GitHub https://github.com/Backhage/WPF-MVVM-Sample