ISerializable

Videos: Beautiful Builds, and a Second Look at Unit Testing

Roy Osherove — Thu, 16 May 2013 23:16:59 +0000

While at the msswit conference in the Ukraine, I got to speak on two subjects with the following videos:

Beautiful Builds: Maintainable, Coherent Build Processes
A Second Look at Unit Testing: what I learned since the first edtion of Art Of Unit Testing

Beautiful Builds: Release Compilation Step

Roy Osherove — Mon, 22 Apr 2013 22:55:48 +0000

Imagine you could only compile once a week. Once every two weeks. Once a month. Scary?

All that code that you write blindly, not knowing whether it even compiles. All those hidden errors lurking, accumulating in the dark. Then, on that special day of compilation, you get to finally find out if you made it. And of course, you most likely did not. Unfortunately, that special compilation day is followed by an even worse day. Demo day.

You are supposed to sit down with your customer, or product owner, and show them all the progress you have made to your application. Most times, compilation day goes sour, and you are stuck fixing last minute, last hour, and last night-Compilation issues only to find out that now, the application isn’t working. So there goes demo day.

You secretly start wondering if there was a way to ‘break the rules’. A way that you could secretly compile your code — maybe on a daily basis?— and see if you left something out. Hell, why not do it every time you check in your code? or even save it? What if you could _continuously_ compile your code? Your life would be so much easier. Not to mention your customer’s life. You could find those compilation errors quickly, and thus fix them quickly while they are still fresh in memory. You could start focusing on that demo now that the code compiles, and see if the app is actually working!

Aren’t we lucky that we all already live with that kind of continuous compilation? At least in static languages, we can see if our code ‘checks out’ by the compiler almost instantly. We can write a single line, or even a single code keyword, and see if it works when the reality of the compiler hits. If we are working in a dynamically typed language, like Ruby or Python, we write tests, and we run those tests continuously , so that we get feedback that the code works. Well, some of us do, anyway. A lot of us just _say_ we do it, but deep down we know it is lip service.

Sometimes we get a ‘fluke’ - we write a function and it fully compiles and runs with no problems with no compilation and debugging errors. That kind of magic doesn’t happen very often though.

Things aren’t perfect. Now that we live in this magical world where compilation is continuous, we start to realize we still have problems with our customer’s demos.

The demos aren’t working. Well, they are working, but not really. they break and they work only partially. And when we try to fix the functionality problems, we break other functionality. We need testing, or, more precisely, _automated_ testing to tell us if our code functions right.

Why does it need to be automated though? Because manual testing takes so much time. It’s really a good waste of money to repeat the same regression tests by a human. We should be using humans for tasks with creativity built in, like exploration testing, but we need ‘automated checks’ for regression testing, to keep telling us we didn’t break anything, continuously.

So we write some tests, and we run them locally every time we are about to check in the code. things feel better for a while, but then we realize the customer demos are still not really working. “Why would the customer tests not be working _now_?” you ask yourself. Turns out, the demos are supposed to be shown on the customer’s machine. The customer’s machine is very different from a developer’s machine. It has weird firewall requirements, it needs active directory permissions to run your application, and the database is shared on a different machine. For you, demo day is also, it turns out, deployment day.

Because you deploy before you demo (usually the day before if you are lucky), it means you have one day every week you deploy. Or maybe demo is once every two or three weeks, so you deploy just once every two or three weeks. If you’re lucky.

Deployment once a week? Now you spend your week compiling and testing code, but you’re still as blind as a bat. You do not know whether all this code will actually work within the constraints of the customer’s machine. Sure, it works on _your machine_, but we all know that doesn’t mean much.You spend all this time writing and polishing your beautiful code, all the while you have no idea whether it will _fit in_ with the hard reality of living on a customer’s machine.

Demo day comes, and you deploy, and your perfectly working code is shamingly crashing, lagging, stalling and basically acting like an angry child in the middle of a supermarket: Badly. Your demo sucks. And now you can’t get any feedback from the customer. Instead, you have wasted your customer’s time, and some of their hard earned trust.

This keeps happening.

Some weeks you get things right, some weeks the new pieces of code just don’t fit the configuration. You have to wait a week between demos to find out if the changes you made to your code or configuration files actually work, because, well, you deploy once a week.

You secretly start wondering what happened if you broke the rules and got your own little machine that looks and acts just like a customer’s machine. If you had that kind of machine locally, you could try and deploy to it on a daily basis, and find out if your code actually works after deployment. If it didn’t you could fix it way before demo day. And then you can use the demos to actually get feedback on the functionality of your application. On second thought, what if you went all out and _automated_ the deployment to the fake customer machine? then you could test your deployment continuously! On every check in.

Now that would be quite beautiful.

Deployment testing is like a compilation step for your release cycle. It verifies that your product, when deployed, can face the harsh realities of a production machine. It should happen continuously, so that you do not find out at the last minute that your code or configuration, is not able to handle the current reality.

For deployment testing, you need to create a _staging_ environment. This environment mimics the production environment as closely as possible, and it should not be contaminated with compilers, editors or development tools.

How do you test your deployment with a staging environment? You run acceptance tests ,and hopefully also all the other automated tests you’ve written, against the application deployed on staging. For example, you could run browser tests (using selenium or capybara — google those) against a web application installed on staging. What happens if you _do_ need to debug something that only seems to happen in the staging environment? That’s why you have a ‘test’ environment. think of ‘test’ as ‘staging + debugging tools’. It can be ‘dirty’ in that you can use it to examine things more closely, but in an environment that can simulate real world difficulties.

The environment right before ‘test’ is ‘dev-test’. that can either be a developer local machine, or a continuous integration build agent, that usually just compiles and runs automated tests.

To me, a beautiful build, is one that encompasses all the levels of confidence we just discussed: Compilation, automated testing, automated deployment, and deployment testing.

If possible,I take the next logical step - I also deploy to a production machine in an automated manner - the same code that has passed all the other stages.

I, and many others, call this chain ‘Continuous Delivery’. (will be part of my builds book)

April 18: Refactoring and Design Skills for Test Driven Development Workshop

Roy Osherove — Wed, 10 Apr 2013 22:10:19 +0000

When? April 18-19

Where? Oslo

How much? 11,900 NOK

How to register? Send me an email.

The Problem

You have been trying to learn TDD, and it’s going pretty well, but your code looks horrible. Your design skills are lacking, and trying to let TDD drive the design without having design skills can lead to a very problematic, although testable, design of your code.

Objectives

I usually do not focus about design in my TDD courses. I believe that separating the learning about the core skills of Unit Testing, TDD, and Design should be separated so that the learner will not feel overwhelmed. This course is a complement to the Art of Unit Testing course I am teaching. This course is specifically dealing with design skills, and assumes that you already know how to write unit tests.

Assumed: You already have some experience writing unit tests.

1. Clean Code and SOLID Design Principles
2. Design for Testability
3. Refactoring patterns on hard to test legacy code
4. Writing tests against refactored code
5. When it does and does not make sense to refactor
6. We will also take a look at open source projects and try to see how we would refactor them.

Materials

All students get a PDF of all the slides in the course, in downloadable form.

Agenda - Day 1:(09:00-16:00)

From TDD Kata to Design Skills
Single Responsibility Functions
Single Responsibility Classes
SOLID Principles
Drills throughout the day

Agenda - Day 2:(09:00-16:00)

Working with Legacy Code
Refactoring for Inversion of Control
Refactoring for Open Closed
Liskov Substitution Problems
Refactoring for Dependency Injection
Drills throughout the day

Two workshops on Beautiful Builds, Refactoring and Design Skills

Roy Osherove — Sat, 06 Apr 2013 21:21:12 +0000

This April, I will be in Kyiv, speaking at the Microsoft SWIT conference.

I will also be holding two separate workshops before the conference. Two very NEW workshops that I have only done once or twice before.

The first one is the Refactoring Skills for TDD workshop. April 23rd.

The second one is Beautiful Builds in .NET . April 24th.

Find the agendas below and location, payment and other details at the links mentioned above.

---------------------------------------------------------

AGENDA: REFACTORING SKILLS FOR TDD IN .NET AND JAVA

The Problem

Objectives

Assumed: You already have some experience writing unit tests.

1. Clean Code and SOLID Design Principles
2. Design for Testability
3. Refactoring patterns on hard to test legacy code
4. Writing tests against refactored code
5. When it does and does not make sense to refactor
6. We will also take a look at open source projects and try to see how we would refactor them.

Materials

All students get a PDF of all the slides in the course, in downloadable form.

Agenda - Day 1:(09:00-16:00)

1. From TDD Kata to Design Skills
2. Single Responsibility Functions
3. Single Responsibility Classes
4. SOLID Principles
6. Working with Legacy Code
7. Refactoring for Inversion of Control
8. Refactoring for Open Closed
9. Liskov Substitution Problems
10. Refactoring for Dependency Injection
11. Drills throughout the day

-----------------------------------------------

BEAUTIFUL BUILDS IN .NET WITH ROY OSHEROVE

The Problem

Being able to deliver fast, and get feedback fast, is a necessary requirement for any kind of agility in software development. But most of our builds, if we have any, look like pieces of gum and string hanging together, held together with some spit. Many projects are barely able to deliver something every month.. We will cover:

Objectives

In this workshop we will learn common patterns and anti patterns for automating the build process, making builds fast, and continuously deliver, while still being able to maintain and understand our builds scripts and process, based on http://beautifulbuilds.com

Understand how automated build scripts and continuous integration servers work best together
Know how to choose the right tools for build scripts and CI based on common and future build requirements, such as auto scaling, amount of projects, ease of maintenance etc.
Learn common solutions and patterns for making builds faster, maintainable and coherent
Understand database migrations and upgrades
Understand advanced features of CI systems such as branch builds, gated commits, artifact sharing, build chaining, and when to use them
Learn to create a holistic view of the build process, build environments, and the delivery process

Materials

All students get a PDF of all the slides in the course, in downloadable form.

Agenda - Day 1:(09:00-16:00)

Comparison of build script and CI tooling
Build Script Patterns
CI Patterns
Build Process Patterns
Database Migrations and Upgrade Patterns
Build and Delivery Environments

Acceptance Frameworks Vs. Specification APis

Roy Osherove — Fri, 29 Mar 2013 14:40:35 +0000

I see two forms of ‘BDD’ tools floating in the wild.

The first form, let`s call it ‘deep BDD’ for now, requires you to go through a special langauge filter, before translating it with special adapters into executable specifications. Think Cucumber’s Gherkin forcing you to write adapters in code to execute your tests. Or SpecFlow’s Gherkin with .NET step definitions.

The second form, let’s call it ‘shallow BDD’ are tools that only give you an API to develop with, but no natural language interface to discuss with end users, or for giving end users to edit on their own. Think RSpec, MSpec or NSpec – they are literally just libraries that allow you to write your “tests” in a more BDD like API.

Deep BDD tools give you more permission to get out of your comfort zone and talk to a customer, while shallow BDD tools give you more permission to stay in side your comfort zone – your code, and to just stay with yourself, coding into the night, not having to talk to anybody, still feeling you’re awesome because you are dong ‘BDD’.

In that way, shallow bdd tools are just shiny wrappers on unit testing tools, while deep BDD tools make us work harder for communication.

Which Specification Style Framework in .NET are you using?

Roy Osherove — Fri, 29 Mar 2013 13:28:33 +0000

Which one are you using?

Using System.Transactions.TransactionScope to Rollback Database changes under an integration test

Roy Osherove — Thu, 28 Mar 2013 22:51:05 +0000

It has been several years since I came up with the idea of database rolled back tests based on com+ transactions, which later became ServicedComponent tests, which later became TransactionScope aided tests.

At some point, a DataRollback attribute was added to NUnIt, but them removed for some reason, that used this idea. I know it exists in MbUnit…. ANYWAY.

I never blogged about the TransactionScope solution in this blog,

so here is a very simple way to rollback database changes that your code under test performs under an integration test, so that the DB is not dirtied up for the next test Just use System.Transactions.TransactionScope class:

Poll> Which IoC frameworks Are you actively using in your current .NET projects?

Roy Osherove — Mon, 25 Mar 2013 10:19:16 +0000

Which ones do you actively use?

TDD Master Class Online: Get Each Day Separately for $59

Roy Osherove — Fri, 22 Mar 2013 21:43:47 +0000

Due to public demand, and as part of the big experiment I am doing, you can now have TWO ways to get my TDD master class online:

You can get the whole master class thing in one big giant course, for $500 (use coupon ‘maintainability’ to get 30% off that until end of day today, Seattle time)
You can download each of the days separately for $90 a pop:

There will NOT be any upgrade path if you have already purchased a specific day and want the full course, unless I see people truly explode about that.

Let us see how people’s wallets vote! feedback is appreciated. If you cannot purchase, do let me know on twitter why!

Osherove online TDD master class at 40% off for a few hours.

Roy Osherove — Thu, 21 Mar 2013 13:20:28 +0000

FYI, for the next few hours, I am offering a 40% off my TDD online training course ($300 instead of $500). use coupon code ‘readability’ on the course page.

This is an experiment I am doing, and will be doing others, but with higher prices.