Could TDD be oriented to another kind of testing different from unit testing?
While that might be possible under some interpretation of TDD, I think the main point of TDD is to write the tests before any production code. Given that, you won't have a large system to write integration or functional tests for, so the testing is necessarily going to be on the unit level.
Behavior-Driven Development (BDD) applies the ideas of TDD at the integration testing and functional testing level.
The red-green-refactor cycle of TDD is supposed to be quick, really quick. Fast feedback keeps you in the groove. I've seen approaches to TDD that take a full story, express it as a test, then drive development to pass that (large-ish) test. It's nominally TDD (or maybe BDD), but it doesn't feel right to me. Tiny steps, unit tests, is how I learned TDD, how I think of it, and how it works best for me.
Technically TDD is a way of doing things, not just about unit testing, in theory it should drive all the development process.
In theory the philosophy is that testing drives development, for a more complex scenario, like integration between systems, you should define the integration test, then code to pass those integration tests (even if the test are not automated)...
Of course YES. TDD relies on automated tests which is an orthogonal concern to the 'type' of tests.
If you concentrate on idea, not technical realization, than yes. What I'm saying is if,just for a moment, you forget about unit testing, and focus on idea of writing tests first, before writing implementation in order to achieve clearer design than it can be done even on system level.
Imagine this, you have some requirements. Based on that you write User Acceptance Testing tests - tests on high level that capture functionality. Next you start development - you already have use cases in form of UAT test. You know exactly what is expected, so it is easier to implement desired functionality.
Other example is project based on scrum. In planning meeting you discuss/create/have user stories that are later developed during sprint. Those user stories can actually be UAT tests.
Anyway way I see TDD as way of specifying design upfront, not application testing cycle/phase/methodology. Reason why TDD is perceived as synonym for unit testing is that unit tests are as close to developer as possible. They seem natural way for developer to express functional design of a class/method.
Certainly! TDD does not require unit tests, not at all. Unfortunately, this seems to be a common misunderstanding.
For a concrete example, I drive the development of an open source mocking library of mine (for Java) entirely with integration tests. I don't write separate unit tests for internal classes. Instead, for every new feature or enhancement I first add a failing acceptance (integration) test, and then change or add to existing production code until the test passes. With the eventual refactoring step, this is pure TDD, even if no unit tests get written.
Related
I am aware of what Unit testing is but When I read about Test Driven Development, I got confused.
Is unit testing something you do ahead of the code-base following the test-first then develop process? or is it something you do mid or after development so you would just refactor some parts of the code-base(which is what I am doing in the project).
I would highly appreciate any enlightenment.
Test Driven Development means, that you write the unit tests before implementing the new feature. With this technique the developer will focus on writing only the code necessary to pass the test. Designs can often be cleaner and clearer than is achieved by other methods.
But compared to normal unit testing, the developer needs a lot more experience to follow this technique. You need an understanding of the implementation including a vision of all layers involved or needed for this requirement, before starting to code (which is always the better way). Otherwise you will have to refactor a lot of code afterwards.
Personally I like this approach, but as I said it requires more experience.
If you are talking about unit testing only, this should always be part of the development process. Often you are writing your tests during development, sometimes when you think you are done. And if you need to refactoring an existing method, then it is also useful to write a test first to ensure you will not break existing functionality.
You should write unit tests as soon as you care that the function is performing properly. If you are doing TDD, that means you write the unit test before you write the unit. Otherwise, that means you write the test very shortly after creating the unit itself.
Our company is in the process of improving the code quality and processes to adopt when delivering a piece of code. My question is concerned to unit testing and I wanted to gather information on the processes you adopt when you are asked to implement a functionality.
Is TDD a form of unit test. From what i understand in TDD, you write your test first (which fails), write your code and then run your test which should pass. It may be that the code will make external method call. But how are we suppose to know about the stubbing required when we are writing our test first?
When you are building your application prior release, what kind of test do you include in the build? Does the build run your integration test or does it run only your unit test?
Apart from TDD, do you write any other kind of test. Sorry if the question are slightly distorted. Your experience on how you undertake development is highly appreciated. Thanks
TDD can be a whole lot more than Unit Testing - so I'd say that Unit Testing is just a part of TDD. The methodology as a whole I think can include creating tests (expressing expectation/requirement of correct behaviour) on the result of any process in the software development. Be that writing code, build scripts, deployment scripts, database scripts, data import/export/transformation... whatever you need to do you should ask yourself, "How can I prove this has worked? Can I automate a test for that?"
As an example: something that is often overlooked because it falls out of scope of Unit Testing but is a very valid test, and one that is important to front-load in the development process is deployment.
If a software development cannot be easily deployed to the production environment without significant effort and change (to the software or environment architecture) it is important to know this up front, rather than a week before it has to go live. Once you have that process nailed, wouldn't it be nice to have a way of testing to make sure that it was correctly deployed?
When you understand that process - why not script and automate it? If you know the requirement is that it must be deployed, why not write a test for that before even doing it?
I've said it before but I'll say it again - the best resource I've found on the subject is Growing Object-Oriented Software, Guided by Tests - which is part of the Kent Beck Signature Series.
TDD is not about testing. TDD uses tests to drive the design of your code. TDD produces tests as a happy side-effect of designing your code by writing the tests first, but it's not about testing: it isn't a testing methodology and the purpose is not to produce tests.
Is test driven development a form of unit testing?
No. It is a design methodology.
From what I understand in TDD, you write your test first (which
fails), write your code and then run your test which should pass.
You're missing a very important step. You write your test first, you write your code until your test passes - and then you refactor. The tests permit you to refactor safely, ensuring that the desired behavior continues to work while you adjust your design. The tests also guide you to testable code, promoting smaller methods, shorter parameter lists, and overall much simpler design than other methodologies lead you to.
Apart from TDD, do you write any other kind of test?
When I do, it's usually a sign that I've failed to do TDD properly (but it certainly happens). We have both unit tests and user acceptance tests; both can be written prior to code, but sometimes our user acceptance tests are written later in the development cycle. They shouldn't be, but sometimes they are.
TDD is about design during the 5 minutes or so of your original Red-Green-Refactor loop. But it's arguably about testing forever after since there is nothing left to design - your TDD tests then become part of a perfect test harness to detect regressions caused by further developments. So yes, I guess you could say test driven development is a form of unit testing :)
But how are we suppose to know about the stubbing required when we are
writing our test first?
TDD often requires a (quick) prior modelling session where you flesh out the big picture classes your SUT will collaborate with.
However you need not go into the details of how these collaborators work. With mocks you basically apply wishful thinking that their implementations will behave correctly when you have TDD'd them at some point later, so for now you can just concentrate on the SUT.
When you are building your application prior release, what kind of
test do you include in the build? Does the build run your integration
test or does it run only your unit test?
When you practice Continuous Integration, your unit tests are supposed to be run each time so you can theoretically take any (non-failed) build and use it as a release build.
However, you may want to run automated or manual integration/acceptance tests as well before releasing your version. GUIs for instance, are usually not easily unit testable so acceptance/integration testing is a good way to track bugs in them.
You have several questions here, ill try to address them in a logical order
Is TDD a form of unit testing?
Id say "yes", in the sense it creates unit tests, even if it isnt the only benefit of using TDD. On the topic stressed by commentators, but not mentioned in your question: TDD not only ensures test coverage and documentiation (good tests are one of the best form of low level code documentation). Using TDD forces you to make certain design decisions, usually improving the overall app design.
Do You write other tests?
Well, I don't write any other unit tests. The point of TDD is the development of the code parallel to the development of the tests. By writing software in a cycle - single test, only enough code to pass it, you're sure that your tests document all the functionality and behaviour you require from your code and you make sure that the code is testable (you have to write it that way doing TDD). There should be no need for additional unit tests
There are other kinds of tests that you should use tho. Integration tests come to mind first, but there are other, like acceptance tests. If you have those automated, you will have it easier on you. Its not you who should be writing acceptance tests - it should be your customer/stakeholder, and You should be helping him on the technical part of writing them. You may be interested in Fitnesse http://fitnesse.org/ - its a tool that helps non-technical people build acceptance tests.
About the stubbing?
Its kind of difficult to discuss this without concrete examples. All i can say right now is - just write the code one test at a time. If you do so, there are chances you wont encounter a situation where you have a complicated class and think about how to stub around its complex dependencies.
What tests should be included in the build?
Id say - all of them, if it is possible!
We're running a project on which we started adopting test-driven design long after the development was started.
We have both unit tests and integration tests. Integration tests are run on a real database, initialized in a known state before the tests are run.
As we write tests, we start noticing than even for classes that could be tested in the "standard way", in isolation & with mock objects, it has actually become faster, and cleaner (read: shorter & easier to understand code) to just use real objects/services directly talking to the database, rather than cluttering the test class with complicated mock objects setup.
Is there anything wrong with this approach?
Nothing wrong with it, at all. On the contrary, based on my experience I would say that it's wrong to favour unit testing. The perception your team had that tests "become faster, and cleaner" is the same I had many years ago and since then.
I would even suggest that you drop unit tests altogether, and continue investing in integration tests. I say this as someone who develops a testing library with a very sophisticated mocking API, who gave isolated unit tests the benefit of the doubt for years, and then finally came to the conclusion that integration tests (after having written many tests of both kinds) are so much better.
One correction, though: unit tests "in isolation & with mock objects" are not the "standard way". As you probably know, Kent Beck is the "father" of TDD and the inventor of JUnit. But guess what, Kent did not use mocks at all in his TDD unit tests. Strictly speaking, the "unit" tests written by the guy who invented TDD are closer to integration tests, as they make no effort of isolating the tested unit from its dependencies. (This is a common misunderstanding about unit testing. For an accurate definition see this article by Martin Fowler.)
If you are using real objects/services, then you don't know why your tests failed. E.g. you changed something in service implementation, or renamed database field, or there your network is down - you have 50 failed "unit" tests. Also you can't do test-driven development in this case, because dependencies which will be required by class you are testing should be implemented before you writing test. Can you foresee which API will be required by consumers of your service? That will lead to less usable API and code which not used at all (parameters, methods, etc).
If your tests take a lot of efforts to arrange mocks, then:
tests should be short and simple
don't verify what other tests already verified
dependencies should be easy to interact with
try to follow Single Responsibility Principle for your classes (both dependencies and sut)
try to follow Tell Don't Ask Principle - instead of asking many questions to dependency, tell it what you want
I want to introduce Unit Testing to some colleagues that have no or little experience with Unit Testing. I'll start with a presentation of about an hour to explain the concept and give lots of examples. I'll follow up with pair programming sessions and code reviews.
What are the key points that should be focussed on at the intrduction?
To keep it really short: Unit testing is about two things
a tool for verifying intentions
a necessary safety net for refactoring
Obviously, it is a lot more than that, but to me that pretty much the sums it up.
Unit tests test small things
Another thing to remember is that unit tests test small things, "units". So if your test runs against a resource like a live server or a database, most people call that a system or integration test. To unit test just the code that talks to a resource like that, people often use mock objects (often called mocks).
Unit tests should run fast and be run often
When unit tests test small things, the tests run fast. That's a good thing. Frequently running unit tests helps you catch problems soon after the occur. The ultimate in frequently running unit tests is having them automated as part of continuous integration.
Unit tests work best when coverage is high
People have different views as to whether 100% unit test coverage is desirable. I'm of the belief that high coverage is good, but that there's a point of diminishing return. As a very rough rule of thumb, I would be happy with a code base that had 85% coverage with good unit tests.
Unit tests aren't a substitute for other types of tests
As important as unit tests are, other types of testing, like integration tests, acceptance tests, and others can also be considered parts of a well-tested system.
Unit testing existing code poses special challenges
If you're looking to add unit tests to existing code, you may want to look at Working Effectively with Legacy Code by Michael Feathers. Code that wasn't designed with testing in mind may have characteristics that make testing difficult and Feathers writes about ways of carefully refactoring code to make it easier to test. And when you're familiar with certain patterns that make testing code difficult, you and your team can write code that tries to avoid/minimize those patterns.
You might get some inspiration here too https://stackoverflow.com/questions/581589/introducing-unit-testing-to-a-wary-team/581610#581610
Remember to point out that Unit Testing is not a silver bullet and shouldn't replace other forms of traditional testing (Functional Tests etc) but should be used in conjunction.
Unit testing works better in some areas than others, so the only way to have truly comprehensive testing is to combine it with other forms.
This seems to be one of the biggest criticisms I see of Unit Testing as a lot of people don't seem to 'get' that it shouldn't be replacing other forms of testing in totality.
Main points:
unit tests help both design (by expressing intent) and regression test (by never going away) code;
unit tests are for lazy programmers who don't want to debug their code again;
tests have no business of influencing or affecting business logic and functionality, but they do test it fully;
unit tests demand the same qualities as regular code: theory and strategy, organization, patterns, smells, refactoring;
Unit tests should be FAIR.
F Fast
A Can be easily Automated
I Can be run Independently
R Repeatable
Unit testing is, roughly speaking, testing bits of your code in isolation with test code. The immediate advantages that come to mind are:
Running the tests becomes automate-able and repeatable
You can test at a much more granular level than point-and-click testing via a GUI
Rytmis
My question is, what are the current "best practices" in terms of tools as well as when and where to use unit testing as part of your daily coding?
Lets try to be somewhat language agnostic and cover all the bases.
Ok here's some best practices from some one who doesn't unit test as much as he should...cough.
Make sure your tests test one
thing and one thing only.
Write unit tests as you go. Preferably before you write the code you are testing against.
Do not unit test the GUI.
Separate your concerns.
Minimise the dependencies of your tests.
Mock behviour with mocks.
You might want to look at TDD on Three Index Cards and Three Index Cards to Easily Remember the Essence of Test-Driven Development:
Card #1. Uncle Bob’s Three Laws
Write no production code except to pass a failing test.
Write only enough of a test to demonstrate a failure.
Write only enough production code to pass the test.
Card #2: FIRST Principles
Fast: Mind-numbingly fast, as in hundreds or thousands per second.
Isolated: The test isolates a fault clearly.
Repeatable: I can run it repeatedly and it will pass or fail the same way each time.
Self-verifying: The Test is unambiguously pass-fail.
Timely: Produced in lockstep with tiny code changes.
Card #3: Core of TDD
Red: test fails
Green: test passes
Refactor: clean code and tests
The so-called xUnit framework is widely used. It was originally developed for Smalltalk as SUnit, evolved into JUnit for Java, and now has many other implementations such as NUnit for .Net. It's almost a de facto standard - if you say you're using unit tests, a majority of other developers will assume you mean xUnit or similar.
A great resource for 'best practices' is the Google Testing Blog, for example a recent post on Writing Testable Code is a fantastic resource. Specifically their 'Testing on the Toilet' series weekly posts are great for posting around your cube, or toilet, so you can always be thinking about testing.
The xUnit family are the mainstay of unit testing. They are integrated into the likes of Netbeans, Eclipse and many other IDEs. They offer a simple, structured solution to unit testing.
One thing I always try and do when writing a test is to minimise external code usage. By that I mean: I try to minimise the setup and teardown code for the test as much as possible and try to avoid using other modules/code blocks as much as possible. Well-written modular code shouldn't require too much external code in it's setup and teardown.
NUnit is a good tool for any of the .NET languages.
Unit tests can be used in a number of ways:
Test Logic
Increase separation of code units. If you can't fully test a function or section of code, then the parts that make it up are too interdependant.
Drive development, some people write tests before they write the code to be tested. This forces you to think about what you want the code to do, and then gives you a definite guideline on when you have acheived that.
Don't forget refactoring support. ReSharper on .NET provides automatic refactoring and quick fixes for missing code. That means if you write a call to something that does not exist, ReSharper will ask if you want to create the missing piece.