Automated tests

Few arguments for writing automated tests and/or unit tests:

Happier development team 
– fewer bugs = fewer late nights/weekend work
– more time to add new features
– helps your prevent breaking the code 

Happier users
– fewer defects reaching production 
– no data loose, less application crashes
 
Reduce business costs
– defects are found early in the development cycle
– HOW can we debug is we don’t have tests ? search logs, events in OS = time spent which costs money
 
Reliability
– exactly same test code runs each time
– if nothing is change in code, everything runs the same
– no variance between test runs from human error
 
Faster execution
– quicker than a human performing tests manually.
 
Independent & isolated by other test
– running order doesn’t change the result
 
Reliable & repeatable
 
Test single behavior / logical thing
– it’s ok to have multiple asserts if they are testing the same logical behavior
 
Clear intent / readable
 
Test code should have the same quality as production code
 
Tests should be valuable for development team
 

Why Agile ?

A deep overview, philosophy and different agile development methods can be found on Wiki.

In my opinion the benefits of Agile are:

  • It’s a methodology that’s deliver value to customer, faster.
  • Manage rapidly the change of priorities (Nowadays there is a high market pressures and technology advances. We need to be responsive to change and manage that)
  • Mitigate the risk by continually sharing your progress with your customer in order to validate what you are building is really what they want – DAY by DAY with your customer
  • Reduces uncertainty, remove waste
  • Short time-to-market
  • Increase revenue by focusing on customer value
    • Agile produces the high business value in the shortest time by developing products in iterative incremental manner.
    • Each sprint (2-4 weeks) evolves requirements definition, product design, coding and testing.
    • The result after each sprint is a potentially releasable increment. Each other sprint will evolve the product.
  • Improved quality
    • fewer defects into production (testing always not only at the end of the cycle)
  • Start to get feedback from production
  • Sprint retrospectives – an organized way for improvement

Agile and the Seven Deadly Sins of Project Managing

 

All boats leak.  The question isn’t “is this perfect?”, the question is “will this get me there?” The real goal is to go somewhere.

My notes based on Mike Cohn presentation.

Gluttony

  • fix all dimensions of the project will induce overtime, cut quality
  • add people – risky
  • cut business but that’s could be a problem with management
  • FIX: timeboxes, fix iteration length but variable number of iterations, predictability (velocity)

Lust

  • to much/more features
  • FIX: priority order, see progress, working at a sustainable pace (see picture)

Sloth

  • loosing focus on doing high quality work, not doing testing/unittests
  • FIX: simple design, automate testing, TDD, CI – find NOW if something is broke, pair programming, refactoring

Opaqueness

  • obscuring quality, progress or other attribute
  • for quality: not knowing bugs count, done vs not done
  • schedule: burndown chart
  • FIX: show real progress of the team

Pride

  • we believe that we know everything to build the product => lack of stakeholders and user involvement
  • not learn anymore
  • FIX: retrospective, standups – get feedback, US – work closely with users&customer

Wastefulness

  • misuse of resources (time, motivation, losses of creativity)
  • FIX: timebox, daily standups (small sleep – focus on things),

Myopia

  • teams who don’t see the big picture
  • individuals who work only within their roles
  • FIX: release plans, cross functional teams

Early feedback from your code. Run your tests at build time with Xunit

Developing large applications  having a quality check, now days is a must. Such as quality check can be done in multiple ways: unit testing, automation testing, integration testing, others.The following example will show you a simple way of triggering of unit tests at build time using Xunit.

 

What’s cool about this approach ? It’s handy.

Xunit already has integration with Visual Studio, you can also install Xunit.Net runner extension which allows you to run tests within Test Explorer, but with this approach the unit tests will be triggered after the build is done.

 

Step 1: Create a class library project

Step 2: In Package Manager Console run the following two commands with the default project set to the newly created project:

PM> Install-Package xunit

PM> Install-Package xunit.runners

Step 3: Add reference on the project to xunit.runner.msbuild.dll. This DLL is the root of your solution in …\packages\xunit.runners.1.9.2\tools\ subdirectory.

image

Step 4: Right click, unload project and then right click again and click on edit csproj

Step 5: Add the following snippet at the end of the file just before </Project> element. Note: Assembly file name (UnitTests.dll) is the output file of the project created at Step 1 – please change that.

image

  <UsingTask AssemblyFile="bin\debug\xunit.runner.msbuild.dll" TaskName="Xunit.Runner.MSBuild.xunit" />
  <Target Name="AfterBuild">
    <xunit Assembly="bin\debug\UnitTests.dll" />
  </Target>

Step 6: Add a that will fail test using Xunit framework.

namespace UnitTests
{
    using Xunit;

    public class FutureTests
    {
        [Fact]
        public void DummyTest()
        {
            Assert.Equal(1, 2);
        }
    }
}

Step 7: Rebuild the solution and you should get a build error. Fix the test and rebuild again.

image