15

As a one man band delivering smallish web development projects, I found that nearly all regression issues that clients find in the final development phase of the project could be found with unit tests beforehand.

Unit tests for me somewhat act as a method to ensure the specification is complete.

With the demands of timelines and project management, how do I make unit tests a priority? They almost never feature in my budgeting, and if they do they often get thrown out because of scope creep.

Improve this question

7 Answers 7

Reset to default
9

Try to quantify (read: put a hard $ amount to) the increased time/expenses that build up over the lifecycle of the project - regression testing, bug-fixing, new feature risk and increased time to integrate, etc.

Edit: and of course share this with the clients. :)

Improve this answer
6
  • How would you exactly quantify that?
    – mamoo
    Commented Sep 15, 2015 at 15:26
  • 1
    In my experience customers see these things as extra work and try to cut them.
    – Aasimon
    Commented Sep 16, 2015 at 11:06
  • 1
    @mamoo - track the actual time spent on a couple of existing projects in areas that I felt would be mitigated or negated by the technical practices, compare it to the points/time spent on the project or features, then express it as a likely range to the client. One effective visualization is a trajectory map (think hurricane path map) over time showing the increases and range of debt, time, and costs vs. dates.
    – Jeff Lindsey
    Commented Sep 17, 2015 at 18:55
  • @mamoo, I can write up a couple of case studies that illustrate this in various parts of a big project. Of course you would only notice, if a) you still service the customer with maintenance items after the project is complete or b) you have taken over a project from someone else
    – jdog
    Commented Sep 28, 2015 at 20:17
  • @Aasimon, most customers I meet have had this experience in the past, but do not realise it. For example: "my developer had a heart attack" or "my developers marriage broke up". In this case the cost is that you had to find a new developer and pay for learning how the project works, pay them to rebuild some parts etc. Track that time
    – jdog
    Commented Sep 28, 2015 at 20:19
7

TL;DR

Make unit testing part of your core development methodology, and ensure that test coverage is part of your "Definition of Done." Also, ensure your estimates include the overhead to develop and refactor your unit tests.

How to "Bake In" Unit Testing

How can I make unit testing a priority?

Unit tests can function as both design tools and quality controls. As such, they should be included in your project's "Definition of Done" for each feature or potentially-shippable increment. By baking the unit testing into each increment of your work, you ensure that you aren't stuck doing a lot of post-facto testing at the end of the project.

Prioritization can be handled by making explicit tasks or milestones for the delivery of unit tests. However, this isn't really a very agile approach to the problem. Instead, you would be better off padding your estimates to provide time and budget that can be allocated to the ongoing development and refactoring of unit tests throughout each project's lifecycle.

Improve this answer
1
  • I don't necessarily agree with padding, but in this case I think it is a good idea. I don't have a good idea yet, how much unit testing I need to do to reduce regression issues by 80%, but I know that If I have a 2 day task, 2 hours of unit testing will increase the reliability significantly. I find myself also refactoring a lot when writing unit tests, so maybe I need to add 25% for run of the mill work at first
    – jdog
    Commented Sep 28, 2015 at 20:21
5

Don't ask, don't tell ;)

I guess you're not giving estimates on how much time you spend thinking, and how much writing code, the same principle should apply to unit testing.

As soon as your Unit Testing activity becomes a line in the budget it becomes negotiable.

I never report unit testing as a separate activity (and in principle most of the time you actually don't know in advance exactly how time will be split between writing production code and testing code). Most of my clients don't even know I write unit tests regularly. Unit testing, as well as any other testing you judge necessary to your development activity, is part of your development activity and as such should be counted.

Improve this answer
1
  • thinking yes I do, but its structured thinking, ie. writing down multiple ideas, doing a SWOT, comparing estimates. Agree on the general premise though
    – jdog
    Commented Sep 28, 2015 at 20:22
4

Don't add them as an extra and don't allow them to be negotiated away. Make them part of your budget and schedule and make it clear that this is how you develop. If you would normally say 'task x will take 2 days plus 1 day of testing' then it gives someone the opportunity to say 'well, do it in 2 and don't worry about the testing'. If you say 'task x will take 3 days' then it's harder to negotiate on that front.

As both the project manager and the developer in this situation you are in a challenging situation but with your PM hat on you need to communicate the methodology you will follow before the project starts. That way clients can't be surprised when you tell them that something will take longer because of the testing you need to complete. Explain why it's important to test, what the cost of not doing tests will be (i.e. them paying you to fix bugs) and what the risks of introducing bugs into production systems are. It won't stop people from wanting to cut corners and you may even agree to cut those corners at times. That's a decision for you and your client to make together and as a PM it's your job to communicate the impact on the project (and the eventual project outputs) of such decsions.

Improve this answer
1
  • Agree. I admit I was silly enough to try to explain to clients that it is cheaper for them to get a buggy product and then me to fix the bugs. However this is only cheaper, because my clients don't value their own time as much as they should and they don't consider time-to-market, employee turnover and their own burnt client relationships. Everyone else - don't go there!
    – jdog
    Commented Sep 28, 2015 at 20:25
1

Plan to do so and hold yourself accountable.

Every deliverable is backed by one or more unit tests. The WBS/WBS Dictionary lists the acceptance test for every deliverable or WBS item. These decompose down to unit tests. Requirements decompose to unit tests.

Improve this answer
1
  • 1
    That is a helpful comment to implement it. Thank you.
    – jdog
    Commented Sep 28, 2015 at 20:25
1

Unit testing should be part of "definition of done". It sould not be something to be added as an extra work or some feature that would make life easier in the future it will be hard for them to understand the sw engineering concepts also.

Improve this answer
1

could you not approach a project in a BDD 'behaviour driven development' fashion

https://en.wikipedia.org/wiki/Behavior-driven_development

you can use php spec http://www.phpspec.net/en/latest/

To create a specification class for your feature. create php unit tests for that feature then actually develop that feature to the spec?

Then estimate each feature including time needed for the BDD/TDD parts?

Improve this answer
1
  • I thought about that before the question. I would live to hear some experiences with this
    – jdog
    Commented Sep 17, 2015 at 19:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.