Personal Hack: Write Your Value

Write down your value in a white paper! And from that moment, you will work as if you deserve to have that value.

Money does not mean Value. However, for the economic sake, most of us are working for a living. And we could not live without money. Unless you are at the higher course, I assume Money (income) is Value.

The value I am saying here is your rate per hour. No matter what, where you are working, in the end you can calculate how much you get per hour.

In this post, I want to share

  1. How to calculate your current rate?
  2. Why do we have to write down our value?

To make the system work, both you and I must have some kind of faith.

If you do not, that is ok. You can enjoy the reading or simply stop reading 🙂

I believe it works. That’s why I wrote this page. And later I shared this tip with my team. Now I share it with you.

Calculate Your Rate

The formula is simple

Your Rate = (Total Income in a year)/ (Total working hours in a year)

If you have a habit of tracking your income, your working hours (usually freelancers have). You can easily come up with your rate. Or you have already known your rate (you get paid by your customers).

However, if your salary is monthly basic, and your working schedule follows 9-5 pattern, the formula is

Your Rate = (Salary * 12 + (bonuses))/(40*52)

And The Number?

The number depends totally on you. You make that call. If you still do not know, let take (Current Rate) * (1.5-2). The most important part is you have to write a number. At the end of the journey, what important is not the number, it is the process, the progress that the number triggered.

The Why

Because the number gives you a clear picture, a clear image of the person you want to become.

Because it gives you a clear goal. Think about people who make this wish every year: I wish to have a lot of money. Wow, what do you mean “a lot”?

Because it changes the way you look at yourself. Therefore change the way you look at the world.

Because it helps you ask better questions.

The How

You have to track your total income and working hours every month. An excel spreadsheet should be enough to track.

Whenever you go to work or do something, constantly repeat your value (whispering in your head).

For every problem, you have to solve, ask this question

What a guy with {your number} value will do?

That question will trigger a whole new process inside you. What process is it? I do not know. It depends on who you currently are. However, I know that it will bring you to a new level. The key here is repetition. Do not quit at the first time you ask the question.

I am a Software Developer. I will take an example in my field.

You are responsible for solving a bug.

Depending on the process of your organization, however, I would assume these are steps that should be done

  1. Reproduce the bug with unit test if possible
  2. Fix the issue
  3. Write unit test to verify your fix.
  4. Manual testing

I know there might be more to get a bug done.

Here are some facts I observed

  • A few will follow 4 steps
  • Some will do steps #2 and #4.
  • Some will do steps #2 and #3.
  • ….

Question is, who will you be? What will you do as you are now? Then you can practice asking the question.

What if you know what that guy will do, but you decide to drop some steps?

I hope your inner voice will speak: Hey! That is not what that guy will do.

 

As I said in the beginning, I applied this hack (tip). And I believe it will work. I do not know where it will bring me to. But I do know that I will become a better person in this progress. Since I started, it has given me a lot of courage (writing this post is a big courage). It has helped me shape the way I think when I deal with problems.

I rather give it a go than sit in a corner and do nothing. Right now I am thinking of the moment when I write another post to share the process and the result.

Challenge 30 Days of Non-Alcohol

Drinking is one of my hobby. I love drinking with friends. For the past 10 years, I have been drinking at least weekly. It brings both joy and pain. Joy when I drink, pain the days after. No matter what I still love it.

I have had many terrible hangover days. Each time, I swore to make something different.

Welcome to my biggest challenge:

30 days without alcohol. No exception!

Why?

Experiment! Challenge! The joy of discipline.

I want to optimize my time. Hangover costs too much.

I want to know how my life goes without me spending time on drinking. I want to feel the pain, resistance of discipline. I want to enjoy the winning.

I want them all.

You know nothing unless you try. To win, you have to challenge yourself, have to take action.

What If

What if you fail, my inner voice asks? I do not know. I have to try and make sure I will not fail. If fail, I will start over again. Never give up!

What if after 30 days you drink 30 days to make up the lost? I do not know. But I am sure I am smarter than that.

No matter “what if”, I start it and follow it. In the end, I will feel better. That, I do know!

What if” is the question that hold you back. To overcome it, I simply say: I do not care, I do not know.

Who With Me?

My friends, you have your own desires. Why don’t you give them a trial of 30 days?

At the end of 30th, you will have something to say

  1. Yeah. I made it
  2. Hmm. I fail. Will start it again
  3. Oh. I did nothing. I just spent 30 days out of my life

We all suffer from 2 things the joy of disciplines or the pain of regrets – Jim Rohn.

Let’s get started! Get the job done!

My Thoughts Unit Test Is an Art

It started with my Unit Test Mock and State Live Together. My friend asked me to explain a bit more about my statement

Unit Test is an art.

 

It was such an interesting question when he asked: Why do you have this statement?

He made a good point. I promised to give him my thoughts on it.

Things have no meaning unless you label them.

“What UT is” does not matter much. What you think it is matters.

Unit Test (UT) is Code

First and foremost, UT is code. We write a piece of code to test our production code. When comes to code, we have to

  1. Design
  2. Consider best practices
  3. Consider maintainability
  4. Decide what tools to use
  5. … Thousands of other things

As a developer, I say: Code is an Art.

Point of Views

When working in an organization, when talking about Unit Test, each level has a different view. I will give some of my observations. Please notice that I do not claim anything here. I give my observations.

Non – Technical Manager

He assumes UT is a piece of cake, that we should write UT when there is time.

Problem: There is always NO time.

Half – Technical Manager

Maybe he knows some about UT. He knows the important of UT. He also knows the difficulty of writing UT. Regardless of those he still wants to push for code coverage, and think UT is kind of easy.

Developer

I have not seen many developers have the right mindset about UT. And depending on the technical skill, their UT code quality is less than or equal the production code.

I have not seen many developers study UT seriously. To them, it is a nice-to-have thing.

Because of that mindset, their UT code is a maintenance nightmare. Think about when you have to change your production code; when you have to add new code.

Some developers think UT is a joke, a waste of time.

QA

Here is a funny part. Sometimes I heard a story that in a company the manager expects QA to write UT. Oh God!

 

Many parties just forgot (or pretended to) the fact that UT is code.

When people come to an Art gallery, looking at the same picture. Will they say the same thing? I do not think so.

So What?

People look at things depending on their point of views in life. The same event two people might have different opinions. Sometimes, in order to improve something, we simply need to change our view.

Who should change their view? Developers, in my opinion. Developers get the best advantages out of UT.

Here are a few things I suggest you, developers, to begin with

  1. Do a serious research about UT: What is it? What is it for? What are the best resources to learn it? …
  2. Start today build the habit of writing UT. The key word is TODAY.
  3. After a week, review all UT you wrote. You can ask an experienced developer to give you advice.

And you should not

  1. Study “How to” books at the beginning. “How to” are good only when you know what and why.
  2. Start TOMORROW.

 

Final Thought

What you think about UT will determine how good you are as a developer. When reading this post, some might think of TDD. But NO. I am not talking about TDD. I highly recommend you start small.

By no mean, I am a UT expert. I am just trying to make things better every day.

Want to learn more about UT? This The Art of Unit Testing by Roy Osherove is a good resource.

Unit Test Mock and State Live Together

Unit Test is an art. There is no silver bullet for what to test, how to test, what tools to use. In my opinion, everything depends on the kind of projects, the maturity of the projects, and the skill of developers in the projects.

The Story

Given this piece of code. It is not a real production code nor production quality code. I made it up to demonstrate in this post.

    public class Account
    {
        public virtual bool IsClosed { get; set; }
        public virtual decimal Amount { get; set; }
        public virtual void Withdraw(decimal? amount)
        {
            Amount -= amount.Value;
        }
    }

    public class AccountManager
    {
        private readonly Account _account;

        public AccountManager(Account account)
        {
            _account = account;
        }

        public void Withdraw(decimal? amount)
        {
            if (_account.IsClosed)
                return;
            if (amount == null)
                throw new ArgumentNullException(nameof(amount));
            _account.Withdraw(amount);
        }
    }

This is not a design or best practice post. Let’s focus on the business logic and what/how to test.

There is an Account with 2 properties:

  1. IsClosed (true/false): If closed, cannot withdraw money.
  2. Amount (decimal): The current total amount left in the bank Account. The amount is reduced by the Withdraw method.

I keep the Account class pretty simple.

To manage an account, we have AccountManager. What it does are

  1. If the account is closed, nothing happens.
  2. If not closed, and the amount is null (to demonstrate the point that it is invalid withdrawn amount), throw ArgumentNullException.
  3. If all is valid, the account’s amount is reduced by the withdrawn amount.

How are we going to test that 3 expected behaviors?

The Analysis

I believe at this phase, we have to depend on the mind of the developer. First, we need to recognize what kind of test we should perform.

#1: Look like an interaction test. We want to verify a certain behavior: Nothing happens.

#2: Verify input valid which expects an exception to be thrown.

#3: Look like a state test. We want to verify the account’s state. Why? Because we do not really care how the money is withdrawn. We only care about the amount left.

The Technology

Let bring in the tools we know to test. At this phase, depend on organizations; size and kind of projects. I work on .NET stack. I will use MS Test + RhinoMock (for interaction test).

#1: When the account is closed, nothing happens.

The account class might have many properties (now or later), but I only care about “IsClosed” property.

    [TestClass]
    public class AccountManagerTest
    {
        [TestMethod]
        public void Withdraw_AccountClosed_DoNothing()
        {
            // Arrange
            var account = MockRepository.GenerateMock<Account>();
            account.Expect(x => x.IsClosed)
                .Return(true);
            account.Expect(x => x.Withdraw(Arg<decimal?>.Is.Anything))
                .Repeat.Never();
            var sut = new AccountManager(account);
            // Act
            sut.Withdraw(null);
            // Assert
            account.VerifyAllExpectations();
        }
    }

The main point is at the “Arrange” phase. I expect these behaviors

  1. The “IsClosed” must be called
  2. The “Withdraw” must not be called. It means: Do nothing.

I am happy to see that test passed.

#2: Throw ArgumentNullException

        [TestMethod]
        [ExpectedException(typeof(ArgumentNullException))]
        public void Withdraw_AccountNotClosedAndAmountNull_ThrowArgumentException()
        {
            // Arrange
            var account = new Account {IsClosed = false};
            var sut = new AccountManager(account);
            // Act
            sut.Withdraw(null);
            // Assert
        }

I can use either Mock or real object at this test as far as ensuring the IsClosed is false.

#3: If all is valid, account’s amount is reduced by the withdrawn amount

        [TestMethod]
        public void Withdraw_AllValid_AmountReducedByWithdrawnAmount()
        {
            // Arrange
            var account = new Account
            {
                IsClosed = false,
                Amount = 100
            };
            var sut = new AccountManager(account);
            // Act
            sut.Withdraw(30);
            // Assert
            Assert.AreEqual(70, account.Amount);
        }

At this test, I do not care how the system implemented. Given a valid account, and a valid amount to withdraw, my account must have the right amount left.

Be very careful, fellows. If you use mock here, you will end up with interaction test.

 

As I said in the beginning, unit test is an art. You have to research, learn about it every day. Watch other people do it. Make up your own mind. During my career, I found out that developers have a tendency to jump directly to “The Technologies” phase. “The Analysis” phase is very important.

Happy coding and write more unit test.

The Fruit of Refactoring a Better Way of Unit Test

A while ago, I wrote about refactoring 6K LoC class The main benefit of such a refactoring is to have a maintainable codebase.

Last week, I fixed a small bug. The bug itself is trivial. However, the way I enjoyed the new code and wrote unit test was more fun to share. I called it a beautiful solution. And I loved that work.

The Story

In the Refactoring post, I introduced the School and Student to demonstrate the problems. One day, I got a bug report (speak in the blog language, not my real project language)

When removing a student by student’s id, an exception was thrown if the id is invalid.

The expected behavior is not throwing an exception if id is invalid (or not found). It is just a normal business rule in the application.

To demonstrate the story here is the simplest code

    public class School
    {
        protected internal IList<Student> _students = new List<Student>();
     
        private readonly StudentManager _studentManager;

        public School()
        {
            _studentManager = new StudentManager(this);
        }

        public virtual void AddStudent(Student student)
        {
            _studentManager.Add(student);
        }

        public virtual Student FindStudent(Guid id)
        {
            throw new ArgumentException($"The student you are looking for does not exist {id}", nameof(id));
        }
        
        public virtual void Remove(Student student)
        {
            _students.Remove(student);
        }
    }

    public class Student
    {
        public virtual Guid Id { get; protected set; }
    }

And the consumer code (a simple console application)

    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Welcome to the test");
            try
            {
                var school = new School();
                var studentId = Guid.NewGuid();
                var student = school.FindStudent(studentId);
                school.Remove(student);
            }
            catch (Exception e)
            {
                Console.WriteLine(e);
            }
            Console.WriteLine("Press key to exit.");
            Console.Read();
        }
    }

Once you run the code

Run Client
Run Client

The Manager

Remember that School is a ghost class. And the student management is delegated to StudentManager. Any attempt to fix directly in School class is a big risk.

There is a small issue in the consumer code. The client has to do 2 things

  1. Find a student by id
  2. Ask School to remove that student

They are too much for a client to know and make decisions. What the client wants is the ability to remove a student by id without throwing an exception.

    public class StudentManager
    {
        private readonly School _school;

        public StudentManager(School school)
        {
            _school = school;
        }

        public void Add(Student student)
        {
            _school._students.Add(student);
        }

        public bool TryRemove(Guid studentId)
        {
            var student = _school._students.FirstOrDefault(x => x.Id == studentId);
            if (student == null)
                return false;
            return _school._students.Remove(student);
        }
    }

The StudentManager will take care of the logic.

The Client will be happy

    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Welcome to the test");
            try
            {
                var school = new School();
                var studentId = Guid.NewGuid();
                var studentManager = new StudentManager(school);
                var result = studentManager.TryRemove(studentId);
                Console.WriteLine($"Are you removed? {result}");
            }
            catch (Exception e)
            {
                Console.WriteLine(e);
            }
            Console.WriteLine("Press key to exit.");
            Console.Read();
        }
    }

Why? Because it just needs to ask StudentManager to handle the logic (in a single method call) and deal with result in its own way.

The Unit Test

So far I am very happy with the fix without touching the existing giant class (School class). Good!

Good! How am I going to test this implementation?

The system data access layer uses NHibernate which requires all domain properties virtual. That design brings us a big benefit in term of unit testing. We can either mock or substitute objects.

To understand more about unit test I highly recommend this course from Pluralsight Writing Highly Maintainable Unit Tests.

Due to the complexity of the legacy code, I tended to use Mock (which is an interaction test) rather than Substitute (which is a state test).

Ok, what do I mean by Interaction Test and State Test in this example? We will test the StudentManager.TryRemove method.

What To Test?

From the business logic, we will test at least 2 things

  1. A student is removed if the student id is valid.
  2. If a student id is not valid, do not throw an exception.

How To Test?

The #2 logic should be simple to test. This code will ensure that

    [TestClass]
    public class StudentManagerTests
    {
        [TestMethod]
        public void TryRemove_InvalidStudentId_NotThrowException()
        {
            // Arrange
            var school = new School();
            var sut = new StudentManager(school);
            // Act
            var result = sut.TryRemove(Guid.NewGuid());
            // Assert
            Assert.IsFalse(result);
        }
    }

However, #1 is not straight away depending on the mind of the developer. Here are at least 2 ways to think about it

  1. The implementation has to find a student, then remove him if found. Keywords here are the 2 verbs (find and remove). Some might refer to verify those 2 actions invoked. That is the interaction test.
  2. The other might simply think: it does not matter what it does (the implementation) as far as a student is removed. Before the school has 10 students. After invoking the method, it has exactly 9 students, and cannot find that student in the school anymore. That is the state test.

I would go for the state test.

Everything should be easy if all properties are public. But that is not the case. School holds an internal protected student list. Student has a protected Id setter. And we do not want to expose them as public.

The key is to Substitute them. In the Unit Test we create derived classes and override the method we want to hook in or bypass.

Prepare school and student substituted.

    internal class StudentSchool : School
    {
        public StudentSchool(IEnumerable<Student> students)
        {
            _students = students.ToList();
        }
    }

    internal class IdStudent : Student
    {
        public IdStudent(Guid id)
        {
            Id = id;
        }
    }

They are internal (only visible in the unit test assembly).

Without any change to the production code, I have tests covered

    internal class StudentSchool : School
    {
        public StudentSchool(IEnumerable<Student> students)
        {
            _students = students.ToList();
        }

        public int StudentCount => _students.Count;

        public bool Exists(Guid studentId)
        {
            return _students.Any(x => x.Id == studentId);
        }
    }

    internal class IdStudent : Student
    {
        public IdStudent(Guid id)
        {
            Id = id;
        }
    }
    [TestClass]
    public class StudentManagerTests
    {
        [TestMethod]
        public void TryRemove_InvalidStudentId_NotThrowException()
        {
            // Arrange
            var school = new School();
            var sut = new StudentManager(school);
            // Act
            var result = sut.TryRemove(Guid.NewGuid());
            // Assert
            Assert.IsFalse(result);
        }

        [TestMethod]
        public void TryRemove_ValidStudentId_CountReduce1AndCannotFindAgain()
        {
            // Arrange
            var batman = new IdStudent(Guid.NewGuid());
            var superman = new IdStudent(Guid.NewGuid());
            var spiderman = new IdStudent(Guid.NewGuid());
            var school = new StudentSchool(new[] {batman, spiderman, superman});
            var sut = new StudentManager(school);
            // Act
            var result = sut.TryRemove(superman.Id);
            // Assert
            Assert.IsTrue(result);
            Assert.AreEqual(2, school.StudentCount);
            Assert.IsFalse(school.Exists(superman.Id));
        }
    }

Oh yeah! Superman is removed 🙂 Who needs Superman btw 😛

 

There are pain and joy in refactoring + unit testing code. The more you code with the improvement mindset, the more joy you have. It is a journey where you become better and better after each line of code. Keep going my friends.

Happy weekend fellows.

 

 

 

 

%d bloggers like this: