I'm looking for a good set of resources to get starting on converting to TDD, I always seem to start off with getting unit tests running at first but the more I develop the less I want to write tests for things that I know work. So I am looking to change my mindset and start developing with a TDD mindset
You want Test-Driven Development: By Example by Kent Beck and Refactoring by Martin Fowler. IMHO, they should be sold as a 2-volume set. TDD:BE covers things largely from a the testing side, and shows you some refactoring techniques. Refactoring covers things largely from the refactoring side, and brings up good testing practices. Between the two of them, you should have all you need to get started.
This book is good, and is very new (came out 2009).
Growing Object-Oriented Software, Guided By Tests, by Freeman and Pryce
(source: barnesandnoble.com)
This book came out in 2003, but it contains a complete example from start to finish.
Test-driven development: A Practical Guide, by Astels
(source: barnesandnoble.com)
The Art of Unit Testing
Test Driven Development : By Example, by Kent Beck
(source: barnesandnoble.com)
I'm using Nunit
NUnit
Two classics:
Test infected: programmers love
writing tests.
The bowling game episode.
Related
I want to know that,does BDD just work in acceptance test level? If not, does it work in unit test level as well? Does BDD have any suggestion For Unit tests?
thank you
BDD is just a way of defining the specifications for an area of functionality. The idea is to bridge the gap between technical and non-technical people by using human readable syntax of some kind and to use specific examples to define the desired behaviour rather than talking in the abstract. As such it is a tool to help people work together and define the business' requirements for the new functionality. This is the primary point of BDD. Not testing.
The definitions that come out of BDD are however, useful for acceptance testing as they define the expected behaviour that was agreed upon. As such many great tools like cucumber are available to facilitate automation of these scenarios to cut down on your testing time.
With regard to using BDD for something like unit tests, the idea of using BDD and non-technical descriptions is to help involve non-technical people. If there are no non technical people involved in the creation of your unit tests (which I guess is the most likely case) then why bother with it? Technical people can read unit tests that are properly written, just fine. The unit tests that you're writing will come out of the functionality that is described by your BDD scenarios anyway.
However, if there is some technical detail of what you're working on that you're having trouble describing, and your team are comfortable working in a BDD way then definitely give the non-technical language and specific examples approach a go. I just wouldn't bother using the the human readable language version of the example in your unit test.
Edit: After reading xmojmr 's comment about your question, I can absolutely see the benefit of using BDD tools and syntax to make your unit tests more readable/easier to plan out, but I think this is quite different from BDD in general, which is more about bridging a communication gap.
BDD actually started at the class level. The first incarnation of JBehave was a replacement for JUnit that avoided the word "test". It was only later that the system-level stuff came along after Dan North explained mock objects to Chris Matts, an analyst at the time who was learning how to code.
These days, even unit testing frameworks don't insist that you start your test methods with the word "test", and the frameworks for the dynamic languages are pretty much derived from RSpec, which was a port of JBehave's early functionality to Ruby anyway.
So, yes, it's perfectly possible to do BDD at that level.
Of course, alannichols is right in saying that the audience is different, being non-technical.
So why would you want to do BDD?
As Dan says in that first link, it turns out that talking about behaviour is more useful than talking about tests. In BDD, we just avoid the word test. We prefer talking about examples and how things should behave rather than pass or fail.
By having conversations around the desired behaviour of a system or class, and providing examples of that behaviour, you can explore it more easily than when you're talking about testing.
However, because it's a non-technical audience, I find it's enough to put the "given, when, then" in comments. You can see an example here. You don't need an explicit BDD tool.
If you can't find another dev to talk about the behaviour with, I suggest you find a rubber duck.
I've realised that I really do need to get started on the behaviours and patterns related to unit testing in general and with ruby specifically, as I can then migrate that knowledge to other languages. Are there any really good examples on how to get started? The problem I have is that with the current systems I'm using and working on it seems like getting started with Unit testing is insurmountable.
I've never built a single unit test for operational code other than trying the same fifteen or so online tutorials that show you ruby's core classes seem to function fine. I need to know how to build these tests for my own systems and the mentality of what to look for and test for.
What good tutorials are online that show you how to do more than just test that an assert_true is true and the opposite is false? Even if they're not for ruby, what must-read and must experiment unit testing guide should I read or go over? Preferably one with a step by step tutorial.
Stuff like using these unit tests in actual existing models and frameworks and what to actually test for? I'm still trying to get my head around the testing mentality and I keep getting sidetracked by the different elements. No one's really specifically outlined what mentality you need to approach unit testing with, as all of those who have written guides or tutorials seem to have internalised the logic with which you approach the system.
Any help would be really appreciated.
Technically it's BDD, but I would recommend The RSpec Book because it does a good job of explaining concepts and has extended tutorials. The second section of the book covers Cucumber, so it will teach you that as well.
I know this is a perl tutorial, but I think it's really good for the approach/philosophy: cromatic's and Michael G Schwern's Test::Tutorial pdf. It's the first tutorial I read that said to make your tests fail first, and there's lots of other good tips.
It's really easy to get sidetracked and drawn into details such as code coverage tools like rcov and even more detailed tools such as heckle, flog, flay. These tools are great and they track down bugs but they should be secondary to unit tests being related to design and documentation.
I feel this sums it up - From the agile TDD page
"The act of writing a unit test is more an act of design than of verification."
"It is also more an act of documentation than of verification"
I am looking for some tutorials and guides for unit testing on SAP platform.
So far, I have found some mention of ABAP Unit and of Ruby programming language being implemented on SAP software, making it much more interesting option for unit testing SAP software. However, the information is quite scarce and I would appreciate some help on the subject.
The ABAP Unit Wiki on the SDN is a good place to start, as well as this ABAP Unit Best Practices article.
SAPTechnical.com also has an ABAP Unit overview.
And finally, you should check out the links in this question.
Just with regards to your reference to Ruby on the SAP ABAP platform, what you are referring to is "Blue Ruby". This is a project of SAP's research labs and you can find information about it on the SAP Developer Network wiki
In my testing a year ago, I found that Blue Ruby was much preferable to ABAPUnit in several ways, including the ability to be more true to test/behavior-driven-development principles by (for example) writing a test for a method before implementing the method.
Ruby, of course, also has far more and more mature TDD/BDD libraries than ABAP, which pretty much just has ABAPUnit and the eCATT tools. These libraries (RSpec, Cucumber, etc) seem to work under Blue Ruby. Both ABAPUnit and Blue Ruby have improved a lot since I looked in to them a year ago, but only for the better, I think.
There is an excellent course on ABAP Unit on OpenSAP.com. It is called
Writing Testable Code for ABAP
The URL for the course is: https://open.sap.com/courses/wtc1
Detroubulator (http://www.applicon.dk/Detroubulator/) is a unit test tool for mapping programs (XML transformations) running in SAP's PI product. It's written in Java and might be considered a JUnit/Schematron hybrid.
I know that unit testing is desirable, and I am interested in doing unit testing. The only problem is I have no idea how, or even where to start really. So my question is: How do I learn about and start unit testing? Specifically I frequently write Java code in NetBeans and C# code in Visual Studio and am interested in what tools to use and how to get my feet wet. Can anyone offer any advice for an absolute unit testing n00b?
I know that there are a lot of somewhat similar questions out there but I am less interested in why and more interested in how.
Try to read on StackOverflow, tag unit-testing :)
Is Unit Testing worth the effort?
How to make junior programmers write tests?
What is unit testing?
How do you know what to test when writing unit tests?
Another entry point would be the tags junit and nunit
There are lots of question dealing this.
If you're searching books about Unit Testing, try this thread:
Good C# Unit testing book. There the famous Kent Beck book is mentioned, "Test Driven Development By Example".
It's worth reading!
Good luck!
This Tutorial for writing JUnit tests in NetBeans should give you an idea how unit testing is done technically. NUnit for C# works pretty much the same.
For an advanced view of how to integrate unit testing into you daily development, the standard reference is Kent Beck's "Test Driven Development By Example". Here's a broad overview.
If you really want to understand unit testing (and get hooked), try it out, it should only take a few hours!
First, I recommend downloading a unit testing framework, such as NUnit (if you want to start with .NET / C#).
Most of these frameworks have online documentation that provides a brief introduction, like the NUnit Quick Start. Read that documentation, then choose a fairly simple, self-contained class for which you are responsible. If you can, try to choose a class that:
Has few or no dependencies on other classes - at least not on complex classes.
Has some behavior: a simple container with a bunch of properties won't really show you much about unit testing.
Try writing some tests to get good coverage on that class, then compile and run the tests.
Unit testing is simple to learn and hard to master (apologies for the cliché, but it is appropriate here), so once you've done this, start reading around: for example, guerda has provided several excellent links in another answer to this question.
Start small.
Unit testing (and automated testing in general) isn't a silver bullet, doesn't always apply to every situation and can be a bit of a culture shock. That said, if you're writing software that you're selling or that your company relies on, I highly recommend adopting it. You'd be surprised how many professional development shops don't.
First, get comfortable the mechanics of creating and running unit tests with your development tools.
Then, start with a new (preferably small, but not necessarily trivial) class or method that you want to test. Writing tests for existing code has its own challenges, which is why you should start with either something brand new or something that you are going to rewrite.
You should notice that making this class or method testable (and therefore reusable) has an impact on how you write the code. You should also find that thinking about how to test the code up front forces you to think about and refine the design now instead of some time down the road "when there's more time". Things as simple as "What should be returned if a bad parameter is passed in?". You should also feel a certain amount of confidence that the code behaves exactly the way you expect it to.
If you see a benefit from this exercise, then build on it and start applying it to other parts of your code. Over time, you'll have confidence in more and more of your software as it becomes more provably correct.
The hands on approach helped get my head around the subject better than a lot of the reading material and helped fill in the gaps of things I just didn't understand. Especially where TDD was concerned. It was counter-intuitive until I actually tried it.
Find-a-bug-write-a-test
The next time you find a bug in your code base, before fixing it, write a test. The test should fail. Then, fix the bug. The test should pass.
If the test doesn't pass, there's either a bug in your test, or a bug in your fix.
A person will never find that bug in your code again. The unit tests will find it (and faster than a person can).
This is definitely a small start, but it gets you into testing. Once you've got the hang of it, you'll probably start writing more tests, and eventually get a knack for how code will fail and which tests you need (for example: a test for every business rule).
Later in your progression you setup a continuous integration server, which makes sure your codebase is always solid.
A good start is to buy a good book where you can read about unit-testing.
I have a tips on a book called "Software testing with visual studio team system 2008" and it takes you trough the basics stuff and background to more higher levels of unit-testing and practises.
Check out The Art of Unit Testing by Roy Osherove, it's a good book for beginners since it starts at the very beginning.
I would recommend reading Michael Feathers' "Working Effectively with Legacy Code". Old code often ends up being code that's hard to Unit Test. Feathers' book is a great guide in how to refactor your code to the point that unit tests are a snap to write.
Not exactly an answer to the question you asked, but might be a missing step between where you are, and where you need to be to implement some of the answers others have given.
I am a newcomer to TDD.
What are some of the techniques you guys use on applying TDD to the development of a webapp?
I am looking for advice for a newcomer.
Practical examples or "war stories" would be appreciated. :)
Bonus: What is some of the software you use for TDD (ideally for a LAMP stack).
One way to get a web app testable is to use some design pattern like MVC or similar. The main idea is to get as much code as possible out of the webpages, and move it into classes that are more encapsulated and suited for testing. When structuring the code like that, TDD for a web app is like TDD for any other piece of software.
Check out the Django framework - it has a very powerful testing framework integrated - on top of being a really cool framework!
As far as tools go, there are unit testing suites that run client-side JavaScript code to assert correctness. QUnit and JSUnit come to mind.
Though it's not applicable to LAMP, you might take a look at Stephen Walther's ASP.NET MVC Programming Unleashed, which goes into it in some detail and has some techniques you might use. You might also google "XUnit PHP" and see what pops out.
Since you're at LAMP, you may want to give Ruby on Rails try.