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.
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 have been wrestling with this question for far too long now. I know I need to just jump into one or the other since they are both obviously viable/useful tools, but have been stuck on the fence, researching both, for weeks.
PHPUnit vs. PHPSpec - Which one may lead to better long-term maintainability and programming practices?
I have talked to several seasoned PHPUnit -> PHPspec converts/users who now swear by PHPspec, claiming that it promotes better design thanks to its BDD approach. However, since it is a much newer tool there is a lack of community/tutorials in comparison with PHPUnit.
Currently, my PHP development is focused around Laravel 4 development.
Where PHPUnit is basically baked into the Laravel framework, it seems like that may be the easier choice up front, but I really like the BDD aspect of PHPSpec. However, it seems that PHPSpec doesn't want to play nicely with Laravel's facade setup (which I'm also finding may be a good practice to steer clear of when possible).
My real conundrum is which of these will be more likely to be successfully integrated into an existing Laravel 4 project with zero existing test coverage.
I had an early/brief stab at integrating both PHPUnit and PHPSpec into an existing project, but really just wasn't sure where to begin with writing the initial tests and ended up scrapping them for the time being.
I am really trying to sort out which one may be more worth investing some time into in the long run.
Any resources/insight from anyone who has experienced both would be greatly appreciated.
PhpSpec
PhpSpec is a design tool. It will make your life hard in the beginning if you're not used to TDD (test-first approach).
You'll learn a lot during the process though. You will also swear a lot. Many things, which are considered a bad practice, are not possible with PhpSpec (like partial mocks for example). You'll have to understand it and embrace it. Testing Laravel's facade's is hard, 'cause that's not OOP.
It's much harder to test an existing code with PhpSpec, since you have to make it testable first (which is easier with a test-first approach).
PhpUnit
On the other hand, PhpUnit is a testing tool. You can use it with TDD, BDD or whatever you call it. But you don't have to.
Choice
If your aim is to learn how to design better and you're commited to test-first approach, PhpSpec will help you. If your aim is to test or verify, PhpUnit is your friend.
TDD vs BDD
It's not either TDD or BDD. At least from a code level perspective, they're the same. BDD started as a TDD-redefined, offering a better terminology. Now it goes beyond the code level and it's so much more than that. These days I prefer to use a term proposed by Gojko Adzic - Specification by Example.
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"
Recently I've discovered CouchDB. I want to use CouchApp to build a flash games site. It looks like a perfect fit 'cause this kind of a site is totally document based with a bit of binary attachments.
The only thing I need to learn before I start is how to TDD with CouchApp/CouchDB. I couldn't google any workflow tutorial and I'm not experienced enough to adapt any existing server-side JS workflow to the CouchDB environment.
Your suggestions?
I looked at this and found jsunit and Jasmine.
I settled on jsunit for familiarity and because I had a book with some examples in it (yeah, I know a real scientific decision process).
I got what I wanted out of it, but an not entirely happy about the way of working in a browser as a test runner. I need to look at some ways to automate it in my build process.
My question is same as the title. I have not done Test driven development yet,I have performed unit testing and I am aware of testing in general but I hear it is much advantageous to follow TDD?. So should I opt for it everytime or are there some preconditions... i just need to know some basic or important requirements when i should opt for TDD. Sorry if this question is too trivial.
I would say whenever you are coding for a project. By this I mean where you are hoping to produce code that will be used by people. This is basically all code apart from research where you are learning and discovering new techniques.
Even if you think the project is just a small one often things spiral up out of control without care. You wil be glad for the tests when you find yourself having to refactor a big sprawl of code.
Also note that tdd isn't just about testing. It is a methodology of development that encourages you to create clean and solid designs.
As you are starting out tdd everything. Once you have more experience then perhaps you can back off and determine when to not tdd.
IMHO if you are not comfortable with TDD, trying to apply it in projects where you will need to interact/use legacy code it's much more complex than applying it in a project from scratch. In fact, there is a whole book about this.
HTH
My advice would be to use unit testing as often as possible.
Caveat: In my experience TDD works best when working with technologies you already have some experience with. It's often hard to write test assertions if you do not know exactly what the desired result looks like (For example, try writing the test for an ASP.NET MVC action method if you never wrote an action method in your entire life). In those cases you're probably better off writing unit tests after implementing the code.
If I am developing something without a user interface, I always use TDD these days. After all, you have to test the software. You can either do the extra work and do TDD, or you can do the extra work and cludge together a user client just for testing. The former tests more completely and in a more repeatable fashion.
Doing TDD against user interface code, on the other hand, hasn't really delivered much value for me. For various business reasons I'm restricted to Visual Studio out of the box for my work, and "recording" tests with VS is a huge time sink, especially when you have to re-record them if you change the UI. I do TDD for the business logic behind the UI, but not the UI itself.