Behavior Driven Development

Covering NUnit 2.4.7

Matthew Podwysocki — Tue, 01 Apr 2008 21:34:37 GMT

It's interesting that a flurry of releases of testing frameworks have been released lately with Gallio, xUnit.net and of course NUnit. Charlie Poole recently announced on a lot of the discussion boards I belong to recently that NUnit 2.4.7 was recently released. You can read all about what's been added here with the release notes.

What's New and Interesting?

What's interesting about this release? Well, NUnit no longer depends on log4net, thus getting rid of some dependency issues with regards to the applications under test. What's also interesting is that addition of the RowTest extension to allow multiple sets of arguments to be given to a test. This is the first one that's ever been incorporated into the core of NUnit.

Static Tests in NUnit?

As Andy Stopford noted in my blog yesterday regarding xUnit.net, Charlie recently checked in code to allow static methods for static methods to be tests as well as Setup and TearDown to be static as well. Jim Newkirk, the man behind NUnit and co-creator of xUnit.net, favors that approach of allowing statics. To me, I don't care as much with regards to Startup and TearDown with statics as most of my statics for testing F# is side effect free programming. As it should be with functional programming. Anyhow, what I'd like to see in NUnit is the support for something that I can do in xUnit.net:

#light

#R @"D:\Program Files\NUnit 2.4.7\bin\nunit.core.dll"

#R @"D:\Program Files\NUnit 2.4.7\bin\nunit.framework.dll"

open NUnit.Framework

let rec fib n =

  match n with 

  | 0 | 1 ->  0

  | n -> fib(n-2) + fib(n-1)

  | n when n < 0 -> failwith "Cannot be less than zero"

[<TestFixture>]

let FibOfOneShouldReturnZero() =

  let fibResult = fib(1)

  Assert.AreEqual(fibResult, 0)

If I saw something like this, I'd be a happy man. But until then, I can dream...

Conclusion

Go ahead and pick up your copy today of NUnit. It's been the old standby for many of my projects throughout my career and served me quite well. Next time I'll cover Gallio a little bit as I have neglected it, but it's a huge release.

XUnit.net RC2 Released

Matthew Podwysocki — Mon, 31 Mar 2008 23:31:06 GMT

UPDATE: More posts on the subject

UPDATE: xUnit.NET RC2 New Drop includes ASP.NET MVC support and better GUI runner. Details here.
UPDATE: Added Static Methods mention and F# - Thanks to DevHawk!

I've been a big fan of such testing frameworks as NUnit and MbUnit, but recently I've found myself getting pulled more towards xUnit.net at least to play around with for any of my code samples that I write for this blog and on my own time. I'm not really a fan of MSTest and many I think would agree about its deficiencies. I won't go as far as say Jay Flowers and wear the shirt though...

Another Release?

Recently, Brad Wilson and Jim Newkirk recently announced the release of xUnit.net RC2 on CodePlex. I'd encourage you download the latest bits here. For those wondering what changes happened between RC1 and RC2, Brad has a good writeup on his blog here. What's interesting about this is the removal of the Assert class methods which take a user defined message should it fail. I was never really a fan of those in the first place though.

Another interesting added features was the IUserFixture<T> which allows you to have a startup and teardown for your fixtures in a separate class and therefore reusable, unlike the current way of using no parameter constructors as your startup and the IDisposable.Dispose for your teardown. See the tests in the FixtureExample for details. But here's a snipped version of that code:

    public class DatabaseFixture : IDisposable
    {
        SqlConnection connection;
        int fooUserID;
 
        public DatabaseFixture()
        {
            string connectionString = ConfigurationManager.ConnectionStrings["DatabaseFixture"].ConnectionString;
            connection = new SqlConnection(connectionString);
            connection.Open();
            string sql = @"INSERT INTO Users VALUES ('foo', 'bar'); SELECT SCOPE_IDENTITY();";
 
            using (SqlCommand cmd = new SqlCommand(sql, connection))
                fooUserID = Convert.ToInt32(cmd.ExecuteScalar());
        }
 
        public SqlConnection Connection
        {
            get { return connection; }
        }
 
        public int FooUserID
        {
            get { return fooUserID; }
        }
 
        public void Dispose()
        {
            string sql = @"DELETE FROM Users WHERE ID = @id;";
 
            using (SqlCommand cmd = new SqlCommand(sql, connection))
            {
                cmd.Parameters.AddWithValue("@id", fooUserID);
                cmd.ExecuteNonQuery();
            }
 
            connection.Close();
        }
    }

What the above code allows us to do is to define a class that holds the data from the initialization of the first test, to the cleanup after the last test. Our state is therefore maintained in a reusable manner. As you will note, the startup logic resides in the default no parameter constructor and all teardown logic is in the IDisposable.Dispose method.

    public class FixtureTests : IUseFixture<DatabaseFixture>
    {
        DatabaseFixture database;
 
        public void SetFixture(DatabaseFixture data)
        {
            database = data;
        }
   
        [Fact]
        public void FooUserWasInserted()
        {
            string sql = "SELECT COUNT(*) FROM Users WHERE ID = @id;";
 
            using (SqlCommand cmd = new SqlCommand(sql, database.Connection))
            {
                cmd.Parameters.AddWithValue("@id", database.FooUserID);
                int rowCount = Convert.ToInt32(cmd.ExecuteScalar());
                Assert.Equal(1, rowCount);
            }
        }
    }

Then we can go ahead with our tests, while using the SqlConnection as defined on our DatabaseFixture. After we're done with our test, it goes ahead and calls Dispose on the fixture. I tend to like this approach and it's definitely growing on me.

Why xUnit.net?

For those new to xUnit.net, there are some decent links to help you along. Some of the more interesting ones can be found here:

But, why am I interested in it? Well, let's just say that I think it tackles things in a slightly different manner. I think one of the key pieces that I really like is the Assert.Throws instead of the clumsy ExpectedExceptionAttribute which you must clutter your tests with on the top. I would rather assert that such a thing happened programmatically, so that I may analyze the exception. I can also specify which line I expect during my test will throw the exception, instead of taking on blind faith that my test threw an exception. It may be of the right type, but that may not have been the one you wanted, thus giving a false sense of security.

To use this, just simply use the Assert.Throws<TException>(Assert.ThrowsDelegate) which I've found to be very helpful. Let's look at a quick test of that being used.

    [Fact]
    public void PopEmptyStack()
    {
        Stack<string> stack = new Stack<string>();
        Assert.Throws<InvalidOperationException>(() => stack.Pop());
    }

As you can see, we're pretty explicit about what line will throw the exception, and that's really the key to this scenario. There are a good number of samples provided on the releases page that you should check out. As always with most products that I talk about, I highly recommend reading the tests to really fully understand what's going on underneath the covers. Not only does it help you understand the intent of the program, but you can learn about good coding techniques, design patterns, testing patterns and so on.

Another point that xUnit.net separates itself from the pack is the ability to decorate static methods as facts. This frees you from having to create an instance of your test class in order to call them. Harry Pierson, aka DevHawk, demonstrates its use with regards to F# and testing the parse buffer here. It definitely opened my eyes and a few more avenues as I pursue more F# related work items in the future. Here's just a quick and dirty sample of showing how you can use xUnit.net with F# quite easily, just as Harry's post did.

#light

#R @"E:\Tools\xunit-build-1223-samples\Samples\xunit\xunit.dll" 

open System

open System.Collections.Generic

open Xunit

type Stack<'t> = class

  val elements : LinkedList<'t>

  new() = { elements = new LinkedList<'t>() }

  member x.IsEmpty

    with get() = x.elements.Count = 0

  member x.Push element =

    x.elements.AddFirst(element:'t)

  member x.Top

    with get() =

      if x.elements.Count = 0 then

        raise (InvalidOperationException("cannot top an empty stack"))

      x.elements.First.Value

  member x.Pop = 

    let top = x.Top

    x.elements.RemoveFirst()

    top

end

[<Fact>]   

let NoElementsShouldBeEmpty () =

  let stack = new Stack<string>()

  Assert.True(stack.IsEmpty)

If you notice, the FactAttribute is placed on a static method called NoElementsShouldBeEmpty and sure enough it works like a champ through xUnit.net. I like this approach instead of the pomp and circumstance required for creating classes as shown above with my Stack class. Note the use of the empty parans which forces it to be a void method with no values passed either. But if you run it through the xunit.console sure enough it succeeds like a champ.

What are we missing though? Well, I'm in favor of having a standalone GUI Test Runner much like NUnit and MbUnit have. In fact, Brad has started this and you can get these features from the latest commits here. Mind you I haven't gotten it to work just right yet, but it's a work in progress.

Conclusion

There is a lot to like about xUnit.net and takes a lot of lessons learned from the use of NUnit, MbUnit and others and I think they're doing a good job incorporating issues. This project isn't as active as MbUnit and NUnit, but it's definitely one to keep an eye on. Recent releases of NUnit and Gallio Automation Platform will probably be also covered in the short while as well as they have a lot to offer. Until next time...

Coming to Terms with Behavior Driven Development

Matthew Podwysocki — Mon, 03 Mar 2008 23:25:41 GMT

A while ago, I posted about Behavior Driven Development (BDD) while using the NBehave, and I think I went too far into the tool without going into the whole thought process instead. I've had a series of these blog posts in my head but have been fighting writers block in order to get them out the door.

BDD Introduction

Anyhow, there has been a lot of discussion around BDD lately on the altdotnet mailing list around the definition and applicability of BDD in regards to Test Driven Development (TDD). Subsequently, this led to forming a new group on Google Groups about Behavior Driven Development. It's great to see the community start to gain momentum and talk about it more. I've been following Dan North, Joe Ocampo, Scott Bellware, JP Boodhoo and Dave Laribee on this for a while, but now to come to a centralized place for that knowledge sharing has been invaluable. I've seen too many times that there is a high noise to information ratio out there and we need to clarify a few things before it can really take hold.

Getting back to the subject at hand, if you're unfamiliar with BDD, you should check out Dan North's explanation here. There are a good number of links inside to whet your appetite. To put things succinctly, BDD aims to bridge the gap between Domain Driven Design and Test Driven Development.

Dave Astels, also has a great video on Google Video on BDD you can find here. It's a great video which talks about how TDD differs and evolved from BDD. It also delves into the subject of rSpec, the BDD framework in Ruby. Very worth your time to check it out.

Dave's summation of BDD comes down to the following bullet points:

Don't talk about Units in regards to Unit Testing, instead talk about Behaviors
All software we write has behaviors
There should be no correlation between public methods on a class and test classes
Structure your tests around the behavior of your application
Put emphasis on behaviors (How do I get it to do what I want it to)
Get rid of state based testing and look at interactions instead
Get rid of tests and instead use specifications of behavior (specs)
Get rid of assertions and instead set up expectations

More Places To Turn

I agree with Jimmy Bogard, that going to TDD to BDD in one fell swoop by just renaming your tests. Instead, we should focus on those interactions between the systems and less on the physical implementations of the code. We should also focus on the expectations inside our code as well. Mocking and the use of Rhino Mocks or your other mocking framework will do nicely in here. Brian Donahue also has some nice stabs at BDD as well here, here and here. If you're up in the Philly area soon, Brian will be making the rounds doing BDD presentations...

Dave Laribee has also put some thought into BDD as well with a particular set of classes he has written to help with BDD that you can check out here. Also if you've paid attention to the BDD mailing list on Google Groups, you will note that Scott Bellware also has a framework up on Google Code called SpecUnit which is an extension to NUnit to support naming conventions of BDD inside of the xUnit type frameworks. Very cool ideas coming out!

Wrapping It Up

I encourage you to join the BDD list, read the links, and learn more. I find it's a more intuitive way of proving the behavior of your application (Note that I didn't say test). I find that it bridges the gap between Domain Driven Design and Test Driven Development quite handily especially in regard to using the ubiquitous language. It's important that naming and ubiquitous language comes into play when using BDD, because you can share your specs and they should be able to read them as well. It's a great gap between user stories and the code you write. If you need help with user stories, check out Mike Cohn's User Stories Applied book. Anyhow, I hope you found this useful as an introduction to some of my many upcoming BDD posts.

Fluency in Fluent Interfaces

Matthew Podwysocki — Fri, 01 Feb 2008 22:47:41 GMT

Scott Hanselman's recent post about the Daily Source Code 14 - Fluent Interface Edition got me to think more on fluent interfaces and a previous post of mine on ObjectMother versus Test Data Builders. Also, it comes to mind in regards to DSLs, both internal and external that has me intrigued. Partially due to my latest involvement with Ruby and F#.

Test Data Builder Example

So, let's revisit that simple example:

public class ClaimBuilder
{
     private DateTime claimDate;
     private Provider provider = ProviderBuilder.StartRecording().Build();
     private Recipient recipient = RecipientBuilder.StartRecording().Build();
     private ClaimLineCollection claimLines = ClaimLinesBuilder.StartRecording.Build();

     public static ClaimBuilder StartRecording()
     {
          return new ClaimBuilder();
     }

     public ClaimBuilder WithClaimDate(DateTime claimDate)
     {
          this.claimDate = claimDate;
          return this;
     }

     public ClaimBuilder WithProvider(Provider provider)
     {
          this.provider = provider;
          return this;
     }

     public ClaimBuilder WithRecipient(Recipient recipient)
     {
          this.recipient = recipient;
          return this;
     }

     public ClaimBuilder WithClaimLines(ClaimLineCollection claimLines)
     {
          this.claimLines = claimLines;
          return this;
     }

     public static implicit operator Claim(ClaimBuilder builder)
     {
          return new Claim(builder.claimDate, builder.provider, builder.recipient, builder.claimLines);
     }
}

As you may note I changed the Build method from the previous post to an implicit operator to save me some coding time when it comes to my builders. This is one of the very very few places where I'd recommend using this operator. Anyhow, then we'd have the calling code to look similar to this for my unit tests.

Claim claim = ClaimBuilder.StartRecording()
     .WithClaimDate(new DateTime(2008, 1, 1))
     .WithProvider(ProviderBuilder.StartRecording()
          .WithName("Robert", "Jones")
          .WithAddress(AddressBuilder.StartRecording()
               .WithStreetAddress("1800 28th St, NW")
               .WithCity("Washington")
               .WithState("DC"))))
     .WithRecipient(RecipientBuilder.StartRecording()
          .WithName(James", "Smith")
          .WithAddress(AddressBuilder.StartRecording()
               .WithStreetAddress("1210 14th St, SE",)
               .WithCity("Washington")
               .WithState("DC"))))
     .WithClaimLines(ClaimLinesBuilder.StartRecording()
          .WithClaim("00308-1")));

This is truly powerful here to make it make sense to the reader instead of the usual black box ObjectMother approach. When building my entity objects for test, this is the main approach I use.

Other Examples

Scott Bellware has introduced the Behavior Driven Development NUnit Extensions which makes heavy use of fluent interfaces. With my deeper dive into BDD, this has been very helpful. Dave Laribee also has me on the kick as well, so lots of thanks to them for pointing me in the right direction, although some may disagree with their directions. But that's for another time and another post.

Jeremy Miller also has fluent interfaces on his StructureMap IOC container project.   Some new parts with registration will be coming up with his new release of version 2.5 as noted here.

Of course I can keep rattling on with others like NHibernate and the ICriteria, Castle Windsor's fluent registration interfaces and so on. The list goes on! Very cool stuff coming out lately... Until next time!

Testing your internals inside out

Matthew Podwysocki — Thu, 24 Jan 2008 23:55:41 GMT

Recently among other places it was asked on the altdotnet list about the strategies of unit testing with regards to assemblies and naming This message here caught my eye regarding putting your NUnit tests in the same assembly as the code under test.

The message states about putting the tests in the same assembly :

There are a couple advantages to this approach:

The nearness of the files will make it easier (and therefore more likely) that developers will work on the test in tandem with the class under test (CUT).
One can make private methods on the CUT into internal methods and then write tests for them, if need be.
Will effectively halve the number of projects in the solution (My current solution has 40+ non test projects), making the solution explorer a little less unwieldy.
I'm thinking this will make it easier for devs unfamiliar with NUnit testing to gain experience with it faster. (I'm currently trying to introduce the concept to 10+ developers.)

And the only disadvantage I have thought of so far:

The production assemblies have a reference to NUnit and contain more types. Slower compilation and load time?

The DEBUG approach

I can say in the early days of my test driven development and others, I was doing this as were many others. We'd go ahead and create a Tests folder inside our project which in turn would create a .Tests namespace. In fact, most people were doing this with their test fixtures:

#if DEBUG

[TestFixture]
public class CustomerTestFixture
{
...
}

#endif

This would prevent of course it being compiled into your production build, had you of course used the release build type. Many shops I worked with never did that...

Early on, I realized that it clutters up your assemblies quite quickly. Throw on top of that any unit testing dll of choice (MbUnit, NUnit, xUnit.NET, MSTest) and any mocking framework as well (Rhino Mocks, TypeMock.NET). I was weary of including any references in my assemblies that I didn't absolutely need.

Testing Internals

One of the main reasons many advocate this approach is that they have access to the internals of your assembly to put them under test. I think the early versions of the Enterprise Library were this way, although I can't remember. I'm sure someone will correct me at some point.

By moving my unit tests to the outside in a separate .Tests assembly, I had to think long and hard about the public API I was willing to expose. In a way, that's a good thing as it made me very clear on the boundaries of my classes and the assembly as a whole. I also tend to have multiple tests fixtures per specification under tests as I want to test it under multiple aspects that may be cross-cutting. I'm moving more towards a BDD way of doing things, albeit I'm in a mixed environment now of TDD with BDD.

Ultimately, though if you need to expose some sort of internals, although should not be the case with 99% of what you do, you have the option of internals visible to attribute such as this:

[assembly: InternalsVisibleTo("Podwysocki.Contracts")]

But to do any more than that, well, brings up a testing code smell and a rant. I think a better approach is to use Dependency Injection and use that to set your expectations through mocks. Then you can test the internals quite easily, but of course testing one expectation at a time and using a double for the other dependencies. That's another lesson I've had to learn over time is the "When to use Mocks". Then again I could be blowing smoke...

Rant Time

I've noticed in MSTest that you can create private accessors for your given objects under test. This just to me screams of being a horrid idea. Very likely during a lot of my refactoring, the internals of my classes under test can and will change frequently. So, that means my unit tests will break quite quickly, then I'll have to right-click on my class again and generate my proxy methods again...

Oh, and generating your unit tests by right clicking on your class just doesn't seem very TDD to me. I'm sure most will agree with me on this, and you wonder why there is xUnit.NET coming from Microsoft guys when MSTest already exists.

Conclusion

So, at the end of the day, I'm more for testing the publicly facing API of your given assembly. That makes you think long and hard about what you want to expose and how granular you make your specifications under test. It's been a long road since I've started TDD and even BDD and I'll admit I still have much to learn..

DC ALT.NET Meeting 1/15/2008

Matthew Podwysocki — Thu, 03 Jan 2008 04:31:32 GMT

We are announcing our second meeting of DC ALT.NET on January 15th at 7PM.

The meeting this month will bring ALT.NET to CMAP. Are you a developer who always keeps an eye out for a better way? Do you look outside the mainstream to adopt the best practices of any development community, including Open Source, Agile, Java, and Ruby communities? Are you always looking for more elegant, more simple, more maintainable solutions? If so, then you might be an ALT.NET practitioner!

This group follows the Open Space Technology model. In Open Space, a facilitator explains the process and then participants are invited to co-create the agenda and host their own discussion groups.

This model follows the four basic principles:

Whoever comes are the right people
Whatever happens is the only thing that could have
Whenever it starts is the right time
When it's over, it's over

Topics for discussion can include the following as well as others:

Model View Controller Pattern (ASP.NET MVC/MonoRail)
Inversion of Control (IoC) containers and Dependency Injection (Spring.NET/Castle Windsor/StructureMap)
O/RM Tools (NHibernate/ActiveRecord/Entity Framework/LINQ)
Test Driven Development
Domain Driven Design
Behavior Driven Development
Design by Contract and Spec#
Enterprise Design Patterns in .NET

Time and Location:
Tuesday, January 15, 2008 7:00 PM

SM Consulting
1306 Concourse Drive
Suite 200
Linthicum, MD 21090

Come, participate, and make your voice heard! Come meet passionate developers like yourself in the active discussion

Making Myself Better for 2008

Matthew Podwysocki — Wed, 02 Jan 2008 03:25:59 GMT

Last year was a very good year for me, but I'm always looking for ways to learn more and better myself for the next year. After all, it is hard to top 2007, the year in which I buy a house, get married and have a great honeymoon in Italy. So, somehow I need to top myself yet again!

Anyhow, these are the things I'm looking to do this year to make me a better designer, developer, etc:

General
- Read a new book a month
- Run a marathon (Well, only running 5 miles a day right now)
General Development
- Give more user group presentations (DC ALT.NET/CMAP/etc)
- Master Ruby and Boo
- Continue deep dive with MVC frameworks
- Contribute more to open source
ALT.NET
- Organize an ALT.NET Code Camp Track
- Stay active in the DC ALT.NET community and the ALT.NET community as a whole
Blogging
- More posts with coding examples
- More downloadable samples
- Be more responsive to questions (sorry about that)
- Explore BDD and DDD more

Rather ambitious, I know, but it's always great to look back earlier on the year to see what changed over the year and what really happened.

Starting Junior Programmers on the Right Agile Track Guidance

Matthew Podwysocki — Wed, 02 Jan 2008 00:53:05 GMT

Part of my job is not only to design and implement solutions for my customers, but also to make my customer's developers stronger as well. During these customer engagements, there are many times when junior developers are involved. My job is to help those on the team to be stronger and then in turn help become leaders.

Where to start?

Well, I could start with a stack of point technology books (ASP.NET, SharePoint, BizTalk, etc) that become obsolete right during their printing, so that's not where I start. You find that many times, the books were written during the beta phase of the product and sure enough, things change, rapidly... But, I will mention a few that earn my admiration that form a basis for a good development background.

So, first things first, surveys are always in order to find out the comfort level with such things as:

Agile Software Development
Scrum
Domain Driven Design
Test Driven Development
Object Oriented Design
Enterprise Design Patterns
Secure Development Lifecycle
Point Technologies (ASP.NET/BizTalk/SharePoint/WCF/WPF/etc)

So, as you can see, it's quite a list of things to cover. But, no matter, we can come up with a list of things to know and teach and how to do it.

Topics to Know

When it comes to making stronger Agile Object Oriented Designers/Programmers, it's important that they know a few topics inside and out. They can be found easily on the net and some books that I will feature later on. Some of these include:

Separation of Concerns
Breaking a program into distinct features that overlap in functionality as little as possible. A concern is any interest or focus in a program. Concerns are synonymous with features or behaviors.
Liskov Substitution Principle
Subtypes must be substitutable for their base types
Law of Demeter
A given object should assume as little as possible about the structure or properties of anything else, including its subcomponents.
Single Responsibility Principle
Every object should have a single responsibility, and that all its services should be narrowly aligned with that responsibility.
Open/Close Principle
Software entities should be open for extension, but closed for modification. The entity can allows its behavior to be modified without modifying the source code.
Interface Segregation Principle
Modules that encapsulate high level policy should not depend upon modules that implement details. Rather, both kinds of modules should depend upon abstractions. Abstract classes should not depend upon concrete classes and concrete classes should depend upon abstract classes. Clients should not be forced to depend on methods that they do not use.
Dependency Inversion Principle
Virtual member functions of derived classes must expect no more than the corresponding member functions of the base class; and should promise no less. It also means that virtual member functions that are present in base classes must also be present in the derived classes; and they must do useful work.

Stocking the Library

Knowing these fundamentals go a long way to making a stronger object oriented programmer. Ok, so reading just an article or two doesn't always make things sink in. Some books may be in order to help as well: Let's walk through some fundamental books for solid developers. Note that these do not include any point technologies, and instead focuses on gaining strong fundamental skills. It's not enough to pick up an ASP.NET book, and boom, you're a solid developer. So, let's go through some of them:

But what about technical books diving into point technologies, well, there are some of them that come highly recommended:

C#/.NET Framework
- CLR via C#, Second Edition (Jeffrey Richter)
- Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (Krzysztof Cwalina)

This by no means is an exhaustive list, but a way to get started. By no means should they read all these books at once and should be tailored for those who need work in those related areas. These books will get the junior developer starting to think abstractly in a more agile mindset. But, how do you reinforce these behaviors in the development environment. It's not enough to read a few articles, a few books and call it a day.

Going to the next level

In order for those developers to get to that next level, paired programming is the key. This can reinforce what they have learned in a nuturing environment and even those who are more senior programmers can still learn a thing or two. One great way to get this kick started is to do Test Driven Development between programmers. Have the first programmer write a unit test and have it fail. Hand the keyboard off to the next programmer and have them make the unit test succeed. Then work on refactoring and move onto the next. Simple things like these go a long way.

Mentoring is also important. Have a mentor assigned to check how the junior developer is doing with learning these new concepts. Follow-up from the mentors is important as you track their progress. Make time to answer questions and challenge them.

What about Agile?

Many organizations in the software development world don't work in an Agile mindset, so what are some of the ways to get there? An Agile Coach is a great way to start an organization on the right step. No, they aren't the Agile Police, nor should they be. The Agile Coach brings quite a few things to an organization. These can include:

Ramping an organization up on agile processes and ways of thinking
Experience with the Agile Process
An effective agent of change
Environment assessment
Being a certified Scrum Master

Holding brown bag sessions is quite important in reinforcing learned ideas and learning new things. Of course you must make it worth people's while to attend. These can also get the junior developers more excited and involved and people can take turns creating these sessions and presenting.

Conclusion

I hope this post gets you in the mindset of changing organizations for the better, getting junior developers to become stronger ones and creating a more dynamic atmosphere. This of course is only the beginning on a lifetime or learning and being challenged. Develop, mentor and inspire!