Things I learned at Agile Up To Here*

After 25 years, it’s time to lose the Windows computer and get a Mac.

Good agile developers are self confident; confident enough to trust interaction designers to do interaction design without distrustful oversight.

There are lots of programmers who understand that relational databases are not the only approach to solving problems.

It is time to build software.

Test-driven-development isn’t fully understood. In fact, software testing isn’t fully understood.

When even the leanest developer in the room sees really high quality BDUF for the first time, they get all woo-woo and want some for themselves.

Getting good software built demands the contributions of many different personalities, competencies, and roles, most of which are new and as-yet ill-defined.

Two programmers pairing can create more and better code in less time than one programmer can (I already knew this, but it’s always good to see it in action).

Even this jaded old fart can still get excited about changing the world.

There are many undiscovered and unfilled product niches on the Web, and one of them is “quality”.

People want a leader with a vision.

Elisabeth Hendrickson (@testobsessed) is a magical woman. To paraphrase Tom Robbins, “she’s been around the world eight times and met everybody twice.” Like a great chef or symphony conductor, Elisabeth knows how to combine the unexpected to create the sublime. She brought together a dozen people from all over the country, each with different skills, background, desires, and expectations, and then she blended them together into a cohesive, happy, effective team.

The pre-written code I arrived with was called “legacy” with a grimace, and was quarantined until discarded. Moral: Non-TDD code is properly regarded like a ticking time bomb.

For interaction design, you can’t have too many white boards, made from porcelain-coated steel, firmly mounted to the wall. For agile development, that isn’t such a big deal.

Story-mapping is a major component of the bridge between interaction design and agile development.

Story-tracking software isn’t quite there yet.

Data-miners think differently. I don’t think like a data-miner.

The Union Pacific Railroad, headquartered in Omaha, is not as “Dilbert-y” as it might seem.

There’s an app for that.

Pointy-haired managers are soooo counter-productive.

While I cling to my tree-based books and papers, bit-based books and papers are actually more capable in many ways. Is my nostalgia based on familiarity rather than quality? Did you just feel the Earth move, too?

Social programming.

While everyone expounds breathlessly about browser-based apps, they still spend the lion’s share of their time using native, client-side apps.

Software patterns are a powerful tool.

Sometimes there’s a necessary part of a program that is just ugly. You can refactor or reconceptualize it, but instead of shrinking it, you’re just moving the ugly part around. I call this the “Irreducible Nugget of Ugliness”, or INU.

I love inventing new TLAs.

While easier than it used to be, it’s still hard for an old software guy like me to keep his hands off.

Some people are perfectly content to not know about the personas and they still get good work done right.

There’s nothing new under the sun.

At a granular level in software development, what used to be easy is hard, and what used to be hard is easy. At a broader level, creating software still remains one of the most difficult things you can attempt.

The power of web development and modern tools is so great that it tempts even me to de-emphasize the user’s goals.

I worry a lot about applying an indelible Sharpie to a precious whiteboard.

Face time is vital when you are creating. If you are creating a product, you need face time with the product team; if you are creating a company, you need face time with everyone in the company.

Flickr is a steaming pile of software.

The only way to really get to know individual people is by devoting attention and time to them. The only way to really get to know your craft is by devoting attention and time to it. This is most definitely not a coincidence.

There are still a few bugs in the system.

The road to mastery is simple: just imagine the problem-set as being far bigger than everybody else does, and then give it attention appropriate to its size.

When you’re in the groove, there’s no 9 to 5.

When you finish something, ring a bell.

Dale Emery (@dhemery) said “I can give you a silver bullet, but be aware that you might be the werewolf.”

Candy remains a powerful motivational tool in the software world. Or maybe it’s just that the brain requires lots of cheap energy.

When you own something, you lose a lot of perspective about it.

Product ownership is far too complex and important to be left to amateurs, even if they actually own the product.

It’s okay to sit down during a Stand-up.

When you are really good at doing some job, you are usually unaware of the important nuances that make you so good.

Establish one really big goal, then establish lots of little, intermediate tasks that will get you to your goal. Then celebrate each task as you achieve it.

Model-View-Controller.

At a certain point the barriers to entry fall so low that no excuses withstand scrutiny.

*Elisabeth Hendrickson has recently opened a new test-and-development training facility in Pleasanton CA called Agilistry. It’s bright and airy, well-lit and well-stocked, and it feels like home the minute you walk in. In order to publicize her new facility, she very generously hosted a week-long intensive learning exercise.

She invited eleven different people with widely varied skill sets, backgrounds, and interests. She challenged them to build a website in five days using the best practices of interaction design, agile programming, and test-driven-development. We christened it “AgileUpToHere” (#au2h) and it exceeded everyone’s expectations (you can see our results here.

Since it was my 15-year-old homophone web site that was being rebuilt, I nominally played the role of product owner, but I was an observer, an instigator, a goad, and a participant. It’s hard to remember when I had so much fun or learned so much.

If you want to learn to be great, I strongly recommend Elisabeth and Agilistry.

Tags: agile, agilistry, design, learning, pairing, programming, software, tdd, testing

This entry was posted on Sunday, May 16th, 2010 at 12:40 PM and is filed under Interesting Stuff, Responsible Craftsmanship, software. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

View the original article here

Rediscovered posts about TDD

I rediscovered some old blog posts about my view of TDD yesterday.

It’s in Swedish and they discuss TDD from three different points of view: safety net, documentative effect and design implications.

I also re-read an article about using TDD in games development and that article mentions an aspect of TDD which I didn’t discuss in my TDD posts: the quick-feedback effect.

The quick-feedback-effect might be the least obvious of the four; but nonetheless I think it might be the most important one from a psychological/human viewpoint.

I want to discuss what I mean with that more deeply in some other post, but in short it’s the idea that getting feedback from your software quickly is nice. TDD reimburses your efforts faster than manual testing, and reimbursement is fundamental to keep programming fun.

Tags: tdd, fun, feedback

View the original article here

#285 Spork

Spork improves the loading time of your test suite by starting up your Rails application once in the background. Use it with Guard for the ultimate combo in fast feedback while doing TDD.

View the original article here

.NET Web Developer

CompanyOneWire, Inc.LocationNew York, United StatesSalarymedical, dental, paid vacation, stock options, great work environment

OneWire is a transformational career management and hiring tool that uses patent pending matching technology that enables companies to confidentially and precisely connect with relevant candidates at every level.

For job seekers, OneWire is a confidential place to manage a career for life and be matched to relevant job opportunities. For employers, OneWire is a recruitment solution that allows them to source candidates at every level and control the entire recruitment process, from candidate discovery to on-boarding. For colleges and universities, OneWire is a campus recruiting tool that enables the Career Services Office to manage and administer the entire process, on- or off-campus.

OneWire has been named one of America’s Most Promising Startups by Business Week (January 2010) and has been featured in NYT, CNBC, MSN, Forbes, NPR, and other major publications.

We have several spots open for top notch .NET / C# / MVC developers to join our team as we continue to change the face of online recruiting. The base technology set is Microsoft-centric (.NET / C# / SQL Server / MVC) along with heavy JQuery, a bit of knockout.js, and some MongoDB thrown in for good measure.

You'll be involved in all stages of the development process, working with a great team at an early stage company.

https://www.onewire.com/p_7421-ASP-NET-MVC-Developer.aspx

View the original article here

Automated hardware testing of Surface with Patty the robot

There's only one thing we love more than software patent arguments, the prospect of Windows 8 and C++ here at developerFusion: robots. And have we got a good one for you this week: robots and Microsoft Surface combined.

Microsoft's robot called "Patty" sits inside the Surface testing lab at Microsoft HQ in Redmond. Its purpose is very simple - how do you test one of the brand new Surface 2.0 devices to make sure it can cope with all of the gestures, touches and more that the device will have to handle, while stress testing it over its lifetime?

Patty solves this problem by encorporating 80 touch "fingers", actuated by pressurised air. These can be rotated in four sections to create multi-touch gestures on the surface. It can even simulate "entire classes" of people, for example students, using the device at the same time. Additionally the robot is capable of moving across the plane of the Surface device to actuate anywhere on the surface.

The testing team also had to put together the software to control the various components of the robot, and to provide a nice interface to make for substantially easier test development.

Find out more about the robot in a video on the Surface blog.

View the original article here

BackTrack 4: Assuring Security by Penetration Testing

Written as an interactive tutorial, this book covers the core of BackTrack with real-world examples and step-by-step instructions to provide professional guidelines and recommendations to you. The book is designed in a simple and intuitive manner, which allows you to explore the whole BackTrack testing process or study parts of it individually. If you are an IT security professional or network administrator who has a basic knowledge of Unix/Linux operating systems including awareness of information security factors, and you want to use BackTrack for penetration testing, then this book is for you.

View the original article here

Design for testing

Design for testing - TDD tutorial - developer Fusion Developer Fusion - The global developer community for .NET and Java programmers .NET Java Open Source Mobile Database Architecture Agile Test Driven Development CQRS nTier Patterns SOA RIA & Web Toolbox Test Driven Development News Tutorials Code Training User Groups Books Podcasts Forum Jobs Home Architecture Test Driven Development Tutorials Design for testing 17 May 2011 | by Kevin Jones | Filed in Comments PDF Test Driven Development LINQ ASP This article was originally published in VSJ, which is now part of Developer Fusion.

Developers generally agree that unit testing is a good idea, however not all of us know how to go about authoring code that is testable. The solution proposed in this article involves deliberately inserting a mechanism for testing at the point that you write the code. For example, if I need to access a database I typically create some kind of data access layer. That layer provides a facade over the database, I create instances of objects from that layer to perform the database access. If I want to test the data access code I need to be able to stub in the database. If I need to test the code that uses the data access code I need to be able to stub in the data access layer. This article will talk about the various approaches we have to writing code that is testable looking at factories, dependency inject and “inversion of control”.

Layer code

The first rule of design for test is really very straightforward. Write your code in layers. Taking the above example; instead of sprinkling your data access code throughout your business logic, separate the data access code into layers. You often see data access code written as two layers, a low level data access layer and a higher level ‘entity’ layer. The lower level layer provides an API that actually talks to the database, maybe through stored procedures, or through parameterized statements and maybe today through a LINQ layer such as LINQ to SQL. The entity layer exists at a higher level and provides methods such as GetAllCustomers, UpdateCustomer or GetInvoicesFor Customer. This layer calls the lower level methods in the data access layer. Depending on the complexity of the application you may not need to separate the code into this many layers, but layering is always a good idea.

Breaking the code into the layers suggested above you will make testing easier as each layer can be tested separately. As the entity layer is independent of the database then no database is needed to test it, all that need be test (and all that should be tested) is the logic within the layer. Another aspect of layering is that no domain specific code should leak into the business code. For example if you are coding a web application the business logic should be in classes that are entirely separate from the UI code. No UI code should be used in the business logic layer. This is easy to achieve in practice, however it is all too easy to see code like this:

ActionView GetUsers(int id) { User.GetUsers(HttpContext.Current); ...}

In this case there is a GetUsers business method, but this is being passed an HttpContext which is an ASP.NETet type. This means that the User type depends on the ASP.NETet assemblies and also that to test the User type you will need to create a dummy HttpContext, which is a non-trivial task that you shouldn’t need to do. Writing the method like this:

ActionView GetUsers(int id) { string startsWith = Request.Params ["startsWith"] as string User.GetUsers(startsWith); ...}

…means that the GetUser method takes a string. This is much better layering and makes the code much easier to test.

Use of ‘new’ considered evil!

One of the cardinal rules of software development is ‘code to abstractions and not to concrete types’, and it cannot be emphasised strongly enough how important this is. By coding to concrete types you are limiting yourself to specific implementations within your application. While at first glance this seems reasonable it means that you cannot substitute those types for doubles when you want to test the code. If the concrete types touch a database, the file system or maybe a web service then this makes testing much harder than it should be. By coding to abstract types and also abstracting away object creation you allow doubles to be substituted in much more easily.

For example, code like this:

public IEnumerable GetUsers() { UserDAO dao = new UserDAO(); return dao.GetUsers();}

…is inherently non- testable, or at least is very difficult to test. This is because the code is using a concrete type UserDAO. This DAO will call some other type which will access a database. This means that either the types used by the UserDAO must be dummied up or the database access must be faked, maybe by using a test database. Instead of this the code should be written against a UsersDAO abstraction, either an interface type or an abstract class. The code would then look like:

public IEnumerable GetUsers() {// IUserDAO idao = GetUserDAOSomehow(); return idao.GetUsers();}

Of course this leaves us with the problem of getting hold of a UsersDAO instance and the rest of this article will discuss those options.

Dependency injection

Dependency injection is a phrase that has come into use over the last few years. It’s an important sounding phrase for a straightforward concept. The basic idea is simple, rather than a type or method, create the objects it relies on, i.e. those objects that are passed into the object or method. Why dependency injection? Well objects depend on other objects, and thus dependent objects are passed into, or injected into the depending objects.

Dependencies can be injected in three ways: parameter injection, setter injection or constructor injection. To examine these uses we will write examples around a ManageAuthors class. This class looks like this:

public class ManageAuthors{ public Author GetAuthor(int id) { AuthorDAO authorDao = new AuthorDAO(); return authorDao.GetAuthorWithId(id); }}

This uses an AuthorDAO class that looks like this:

public class AuthorDAO{ public Author GetAuthorWithId( int au_id) { return new Author() {FirstName = "Kevin", Surname = "Jones" }; }}

As mentioned above the code is difficult to test. The DAO is hard (impossible) to replace. To make this code testable we need to code to an abstraction rather than a concrete type (the AuthorDAO). There are several steps that need to be completed to do this.

The first thing to do is to create an abstract type that the ManageAuthors class can use instead of the AuthorDAO. The AuthorDAO needs to derive from this abstraction. We then end up with classes something like this:

public interface IAuthorDAO{ Author GetAuthorWithId(int au_id);}public class AuthorDAO : IAuthorDAO{ public Author GetAuthorWithId( int au_id) { return new Author() { FirstName = "Kevin", Surname = "Jones" }; }}

Now that we have the interface (the abstraction) in place we can code against it. The simplest way to do this is to use parameter injection. This involves changing the signature of the method to accept a parameter of the correct type:

public Author GetAuthor( IAuthorDAO authorDao, int id){ return authorDao.GetAuthorWithId(id);}

Notice that now the IAuthorDAO is being passed to the method. This makes the method easily testable:

[Test]public void TestValidAuthor(){ ManageAuthors sut = new ManageAuthors(); IAuthorDAO idao = new MockAuthorDAO(); Author a = sut.GetAuthor(idao, 1);}

Where the MockAuthorDAO class looks like this:

public class MockAuthorDAO : IAuthorDAO{ #region IAuthorDAO Members public Author GetAuthorWithId( int au_id) { return new Author() { FirstName = "Foo", Surname = "Bar" }; } #endregion}

Notice that the method now doesn’t create the object it depends on, instead the object is injected via the parameter passed to the method.

One problem with this mechanism is that existing code has to change, in fact it’s worse than that as existing method signatures have to change, this could mean a lot of code changes in a large code base.

To mitigate this we could use ‘setter injection’. Now, rather than inject the dependencies via a parameter the class is re-written to have a property that is set by external code. This property is of the abstract type, IAuthorDAO in the above code. The ManageAuthors class now changes to look like this:

public class ManageAuthors{ public IAuthorDAO AuthorDAO { get; set; } public Author GetAuthor(int id) { return AuthorDAO.GetAuthorWithId(id); }}

This is better as less code has to change. However there is still a danger here. While the ManageAuthors class doesn’t need to change as much, all the code calling it does need to change. The danger now is that all the places where the calling code uses the GetAuthor method have to remember to inject the IAuthorDAO, and this may be missed.

The third option is to use constructor injection. In this case the ManageAuthors class would be changed to have a constructor that takes an IAuthorDAO as a parameter. The code would then look like:

public class ManageAuthors{//readonly IAuthorDAO authorDAO; public IAuthorDAO authorDAO { get; set; } public ManageAuthors( IAuthorDAO authorDAO) { if (authorDAO == null) throw new ArgumentNullException( "authorDAO"); this.authorDAO = authorDAO; }}

Calling this code then involves passing an IAuthorDAO to the ManageAuthors constructor:

[Test]public void TestValidAuthorWithConstructor(){ ManageAuthors sut = new ManageAuthors( new MockAuthorDAO()); Author a = sut.GetAuthor(1); Assert.AreEqual("Foo", a.FirstName); Assert.AreEqual("Bar", a.Surname);}

This has the benefit that it signals to all the calling code exactly how the class should be used, i.e. an IAuthorDAO must be passed to the constructor. Any code compiled against the ManageAuthors class would fail to compile; this is a strong signal that the code is wrong! However, if the ManageAuthors code is used by a lot of other assemblies then re-coding the classes in those assemblies may be a long and tedious process.

Another cardinal rule of software development is ‘don’t change working code’, in this case a lot of working code would have to be touched. To mitigate this, the ManageAuthors class could be changed to have a default constructor that called the new constructor. The class would look something like:

public class ManageAuthors{ readonly IAuthorDAO authorDAO; public ManageAuthors():this( new AuthorDAO()){} public ManageAuthors( IAuthorDAO authorDAO) { if (authorDAO == null) throw new ArgumentNullException( "authorDAO"); this.authorDAO = authorDAO; }}

Care needs to be taken with this approach to ensure that the correct class is instantiated in the default constructor and that new code does not use the default constructor. A better approach may be to have the default constructor create a ‘faulting’ IAuthorDAO, one that logs the fact that it shouldn’t be called and then throws an exception. This means that as the ManageAuthors class is distributed more widely, code using it can be updated more easily.

Of the three approaches to dependency injection, parameter, setter and constructor, constructor is the most widely used. It is generally easier to retro-fit to existing classes and also makes it relatively easy to get existing code to work with the changed ManageAuthors class if the default constructor is kept in place.

Factories

Suppose you find for whatever reason that you cannot or simply do not want to use dependency injection, how do you go about creating objects without the use of the new keyword? One option is to use a factory. The Gang of Four patterns book lists two factory patterns, the factory method and the abstract factory. An abstract factory is simply a collection of factory methods, so understanding factory method leads you to an understanding of abstract factory.

In the factory method pattern the idea is to define a type that is able to create the type you want to use. For the AuthorDAO type above we’d create an AuthorDAOFactory. Factories can also be substituted. So, like any other types, when defining a factory it makes senses to define a base abstract factory and then define concrete instances of that abstraction that our code actually uses. The code for using the factory will look like this:

public Author GetAuthorWithFactory( int id){ AuthorsDAOFactory factory = LoadFactory(); AuthorsDao = factory.GetAuthorsDAO(); return AuthorsDao.GetAuthor(id);}

Here we load the factory (we will see how to do this in a moment), then uses the factory to create the AuthorsDAO object which we can finally call.

The factory code looks like this, first the abstract class:

public abstract class AuthorsDAOFactory{ public abstract AuthorsDAO GetAuthorsDAO();}

…then the concrete implementation:

public class SimpleAuthorsDAOFactory : AuthorsDAOFactory{ public override AuthorsDAO GetAuthorsDAO() { return new SimpleAuthorsDAO(); }}

The factory method pattern gets its name from the fact that there is one method in the class whose job it is to create the object we care about. Notice that this code uses ‘new’. This makes sense – ‘new’ has to be used somewhere, our job is to abstract away where ‘new’ is used.

Notice that the ManageAuthors class uses the abstract AuthorsDAOFactory type which returns an abstract AuthorsDAO type. This means that all our code relies on abstractions, making testing much easier. A test for this method would look like this:

[Test]public void TestWithFactory(){ ManageAuthors manageAuthors = new ManageAuthors(); Author author = manageAuthors. GetAuthorWithFactory(1); Assert.AreEqual("Alice", author.Name);}

Notice that there is no mention of a factory here. The factory is set up purely using configuration. The main application’s configuration file (with the real factory in) would look like:

…while the test configuration file looks like this:

So changing the configuration changes the factory being loaded. This helps solve the mystery of how the ManageAuthors class loads the factory. The LoadFactory method gets the factory type name and assembly from the config file, then uses reflection to load the assembly and create an instance of the factory:

private static AuthorsDAOFactory LoadFactory(){ string typeAsString = ConfigurationManager. AppSettings["factory"]; Type type = Type.GetType(typeAsString); AuthorsDAOFactory factory = (AuthorsDAOFactory)Activator. CreateInstance(type); return factory;}

The configuration file stores the factory as a fully qualified type name which can then be loaded using Type.GetType. This means that not only is testing easier but anytime we want to change the factory it is simply a configuration update.

However, this is still an issue. For example, if you want to test multiple factories then the configuration needs to be changed every time, meaning multiple app.config files in multiple test projects. Sometimes it would be nice to have a configuration option that can be overridden in code. This is where containers and inversion of control come into play.

Inversion of control

A container is an object where an application can store references to other objects and retrieve them later. The references can be stored by having the container read a configuration file and creating the objects, just as we saw for the factory. Or the application can create objects in code and store those references in the container. This is known as inversion of control because the control of creating the dependent object is taken away from the code using that object.

There are various containers available. In these examples we’ll use the Unity container provided by Microsoft as part of the Enterprise Library. This container can be configured in the application’s configuration file:

The first part of the file sets up the Unity configuration section handler. The unity section then configures the container. The unity section defines two aliases, these are there so we can refer to the types through the alias within the configuration file, rather than having to use fully qualified type names everywhere. We then set up aliases for the AuthorsDAO abstract type and the SimpleAuthorsDAO concrete type. Finally in the containers section we create a mapping between these two types. This mapping basically says, ‘when code asks for something of type AuthorsDAO give them a SimpleAuthorsDAO object’.

The configuration for the container must be loaded and parsed. Once that is done an application can then load objects from the container. To do this, provide a simple wrapper class:

public class Container{ private static Container container;// load configuration data here private Container() { ... } readonly IUnityContainer unityContainer = new UnityContainer(); public static Container Instance { ... } public T Resolve() { return unityContainer.Resolve(); } public void RegisterType() where TTo : TFrom { unityContainer.RegisterType< TFrom, TTo>(); }}

Note that the Resolve method is generic. The container will look up the type passed through the generic parameter and return its mapped type. This is used something like this:

public Author GetAuthorWithIoC(int id){ AuthorsDao = Container.Instance. Resolve(); return AuthorsDao.GetAuthor(id);}

…i.e. ask for an AuthorsDAO object and (hopefully) get return a SimpleAuthorsDAO object. Again this lets us test quite easily. Like for the factory, we create an app.config file to configure the container. But we can now also programmatically inject objects into the container. So in the test code we can do this:

[Test]public void TestWithIoC(){ ManageAuthors manageAuthors = new ManageAuthors(); Container.Instance.RegisterType (); Author author = manageAuthors. GetAuthorWithIoC(1); Assert.AreEqual("Alice", author.Name);}

Notice that we are registering a new MockAuthorsDAO with the container before calling the method under test. This will override the instance already in the container and the method under test will resolve AuthorsDAO to MockAuthorsDAO.

This use of containers is very nice. It gives the flexibility of configuration alongside the ability to override that configuration in code which makes managing testing in particular very straightforward.

Types of Test Doubles

In the above code we have written a very simple MockAuthorsDAO class to use for testing. This gets us into the murky world of ‘Test Doubles’. On his ‘bliki’ (www.martinfowler.com/bliki/TestDouble.html) Martin Fowler categorises the various test doubles. He makes a distinction between Dummies, Fakes, Stubs, Spies and Mocks. According to his definitions the ‘mock’ above is probably a Stub. Mocks are more full featured and typically are coded with ‘expections’. Something along the lines of ‘If I call this method passing the value 1, return ‘foo’, if I pass the value 2, return ‘bar’ and so on. Mocks can be built by hand but it is often easier to use a framework designed specifically to create them.

There are several mocking frameworks available and more are becoming available all the time. The most popular is probably Rhino Mocks but there are others such as Moq or NMock.You are recommended to try them and choose the one you prefer.

Conclusion

To make your code more testable you should follow a couple of simple rules. Firstly, write in layers. This makes each layer more testable. Secondly, code to abstractions. If you code to an abstraction you move away from calling ‘new’. This means that you can then get references to objects in other ways. Do this either through dependency injection, factories or containers. Using any of these mechanisms means that these references become pluggable and therefore more testable.

You might also like... Comments About the author Kevin Jones

Kevin Jones has been involved in software development and design for more years than he cares to remember, and has been involved in training and consultancy since 1990. He is the co-author of Se... Interested in writing for us? Find out more.

TDD tutorials Testing In An Agile World: The Heart Of A Developer Web Testing with MbUnit and WatiN Part 2: Controlling Localhost and IIS Express Can developers test their own code? Test-driven development with NUnit TDD books Experiences of Test Automation: Case Studies of Software Test Automation

Software test automation has moved beyond a luxury to become a necessity. Applications and systems have grown ever larger and more complex, and manual testing simply cannot keep up. As technology changes, and more organizations move into agile develo...

TDD forum discussion Asp.Net practical books related by davidkroj (1 replies) robe de mariée_Que pouvez-vous porter pour un mariage d'automne semi-formelle ?_robe de mariée by robesmariee (0 replies) robe de mariée_Que pouvez-vous porter pour un mariage d'automne semi-formelle ?_robe de mariée by robesmariee (0 replies) how to manipulate the design based on IF condition by johngokul (0 replies) ASP Login page to convert to HTML5 by ss2013 (0 replies) TDD podcasts Hanselminutes: Understanding BDD and NSpec with Matt Florence and Amir Rajan Published 1 year ago, running time 0h34m

Scott sits down with NSpec authors Matt Florence and Amir Rajan to talk about Behavior Driven Development (BDD). Where does one start with BDD? Is BDD just TDD with a fancier name or can it really chance how you design software? The NSpec guys set Scott on the right path.

TDD jobs RoR Developer @ Wimdu Wimdu GmbH in Berlin, Germany
Contribute

Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Web Development ASP.NET Quickstart Programming news Java programming ASP.NET tutorials C# programming Developer Jobs ASP.NET Jobs Java Jobs Developer Jobs Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

Join us Sign in Pakistan Username Password Cancel “The generation of random numbers is too important to be left to chance.” - Robert R. Coveyou Send feedback Blog About us Contact us Advertise © 1999-2013 Developer Fusion Ltd Managed hosting by Everycity

View the original article here

Experiences of Test Automation: Case Studies of Software Test Automation

Software test automation has moved beyond a luxury to become a necessity. Applications and systems have grown ever larger and more complex, and manual testing simply cannot keep up. As technology changes, and more organizations move into agile development, testing must adapt—and quickly. Test automation is essential, but poor automation is wasteful—how do you know where your efforts will take you?

Authors Dorothy Graham and Mark Fewster wrote the field’s seminal text, Software Test Automation, which has guided many organizations toward success. Now, in Experiences of Test Automation, they reveal test automation at work in a wide spectrum of organizations and projects, from complex government systems to medical devices, SAP business process development to Android mobile apps and cloud migrations. This book addresses both management and technical issues, describing failures and successes, brilliant ideas and disastrous decisions and, above all, offers specific lessons you can use.

Coverage includes

Experiences of Test Automation will be invaluable to everyone considering, implementing, using, or managing test automation. Testers, analysts, developers, automators and automation architects, test managers, project managers, QA professionals, and technical directors will all benefit from reading this book.

View the original article here

JetBrains releases TeamCity 4.5

JetBrains releases TeamCity 4.5 - TDD news - developer Fusion Developer Fusion - The global developer community for .NET and Java programmers .NET Java Open Source Mobile Database Architecture Agile Test Driven Development CQRS nTier Patterns SOA RIA & Web Toolbox Test Driven Development News Tutorials Code Training User Groups Books Podcasts Forum Jobs Home Architecture Test Driven Development News JetBrains releases TeamCity 4.5 By Mike James, published on 31 May 2009 | Filed in Comments PDF Test Driven Development XML Mono .NET This article was originally published in VSJ, which is now part of Developer Fusion. JetBrains’ TeamCity lets you set up a build server for your projects within minutes and provides out of the box continuous unit testing, code quality analysis, and early reporting on build problems without leaving your favorite IDE.

Version 4.5 includes usability and administration improvements such as tests grouping and project-wide test details, problematic tests, and change log facilities and adds enterprise-level features. User Groups are now supported when defining user roles and notifications, there is extended LDAP support with automatic user profile synchronisation. You can now assign responsibility for broken builds and, in addition to traditional test results handling, TeamCity is now able to parse raw XML reports from ANT’s JUnit tasks, NUnit, Surefire, PMD, and FindBugs. The Mono framework is now automatically detected and can be used as a .NET platform for continuous builds.

You might also like... Comments TDD news Automated hardware testing of Surface with Patty the robot Software Architect programme announced Software Architect programme announced TDD books Experiences of Test Automation: Case Studies of Software Test Automation

Software test automation has moved beyond a luxury to become a necessity. Applications and systems have grown ever larger and more complex, and manual testing simply cannot keep up. As technology changes, and more organizations move into agile develo...

TDD forum discussion Loop through URL's to display and traverse pages using “Previous” and “Next” buttons in VB.NET by TeddyL2013 (0 replies) Convert Video File to Flash Video FLV and Streaming using ASP.NET by thyagi (0 replies) Stream writer to write to multiple files by Sr1234@ (0 replies) Read multiple modbus tcp/ip devices at a time? by stirthe (0 replies) Visual studio 2010 crashes while connecting to mysql database by abhijeet04 (0 replies) TDD jobs RoR Developer @ Wimdu Wimdu GmbH in Berlin, Germany
Contribute

Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Web Development ASP.NET Quickstart Programming news Java programming ASP.NET tutorials C# programming Developer Jobs ASP.NET Jobs Java Jobs Developer Jobs Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

Join us Sign in Pakistan Username Password Cancel “There are 10 types of people in the world, those who can read binary, and those who can't.” Send feedback Blog About us Contact us Advertise © 1999-2013 Developer Fusion Ltd Managed hosting by Everycity

View the original article here

John Smart is wild for agile development

Interested in the agile methodologies and tools? Look no further than this podcast, with Wakaleo CEO John Smart. Learn about Specification by Example, Thucydides, Jenkins, Test Driven Development, acceptance testing, and more.

View the original article here

Professional ASP.NET MVC 2 (Wrox Programmer to Programmer)

Top-selling MVC book from a top team at Microsoft—now fully updated!

ASP.NET MVC 2.0 is now available and shipping with Visual Studio 2010 and .NET 4. A new update to Microsoft’s Model-View-Controller technologies, MVC 2 enables developers to build dynamic, data-driven Web sites. Professional ASP.NET MVC 2 shows you step-by-step how to use MVC 2. You’ll learn both the theory behind MVC 2, as well as walk through practical tutorials, where you’ll create a real-world application. Topics include transitioning from ASP.NET development, as well as an overview of related tools and technologies, including LINQ, jQuery, and REST.

This book is divided into two very broad sections, each comprising several chapters.

The first half of the book is concerned with introducing the MVC pattern and how ASP.NET MVC 2 implements that pattern.

Chapter 1 "NerdDinner" uses a small but complete application to walk you through how to build an ASP.NET MVC 2 application and some of the core concepts behind ASP.NET 2 MVC.

Chapter 2 "Model-View-Controller and ASP.NET" starts off with a description of the Model-View-Controller pattern, explaining the basic concepts of the pattern and providing a bit of its history. The chapter goes on to describe the state of the MVC pattern on the web today as it is implemented by various frameworks, such as ASP.NET MVC 2.

Chapter 3 "ASP.NET > ASP.NET MVC" then covers the ways that ASP.NET MVC is different from ASP.NET Web Forms.

Chapter 4 "Routes and URLs" digs deep into routing to describe the role that URLs play in your application and how routing figures into that. It also differentiates routing from URL rewriting and covers a bit on extending routing and writing unit tests for routes.

Chapter 5 "Controllers" takes a look at controllers and controller actions-what they are, and how to write them. It also covers action results, which are returned by controller actions and what they are used for.

Chapters 6 "Views" and 7 "Ajax" cover views and view engines, and then add a little flavor on top by examining the role that AJAX plays in your views.

The second half of the book focuses entirely on advanced techniques and extending the framework.

Chapter 8 "Filters" goes into detail on action filters, which provide an extensibility point for adding cross-cutting behaviors to action methods.

Chapter 9 "Securing Your Application" covers security and good practices for building a secure application.

Chapter 10 "Test Driven Development with ASP.NET MVC" provides a brief introduction to Test Driven Development (TDD) as it applies to ASP.NET MVC.

Chapter 11 "Testable Design Patterns" shows you real-world patterns and practices for building applications that are testable.

Chapter 12 "The Best of Both Worlds: Web Forms and MVC Together" discusses how Web Forms and MVC work together.

Chapter 13 "What's New in ASP.NET MVC 2" covers what's new in MVC 2.

This book is for web developers who are looking to add more complete testing to their web sites, and who are perhaps ready for "something different."

In some places, we assume that you're somewhat familiar with ASP.NET WebForms, at least peripherally. There are a lot of ASP.NET WebForms developers out there who are interested in ASP.NET MVC so there are a number of places in this book where we contrast the two technologies. Even if you're not already an ASP.NET developer, you might still find these sections interesting for context, as well as for your own edification as ASP.NET MVC may not be the web technology that you're looking for.

View the original article here

Professional Windows Phone 7 Application Development: Building Applications and Games Using Visual Studio, Silverlight

A one-of-a-kind book on Windows Phone 7 development

While numerous books cover both Silverlight and XNA, there lacks a resource that covers the specifics of Windows Phone 7 development. This book fills that void and shares the specifics of building phone applications and games. You’ll learn how to get started with designing, building, testing, and deploying mobile applications for Windows Phone 7. Working examples used throughout the book cover how to design and layout a Windows Phone 7 application, interact with the device, and even sell your applications. Fills the void in the market for an instructional book on developing applications for Windows Phone 7 Offers an overview of Windows Phone and discusses the necessary tools Explains how to work with multiview applications Addresses tool bars, pickers, table views, navigation controllers, application setting, and user defaults Reviews drawing with XNA, using the camera, and understanding basic data persistence

Explore the exciting possibilties of Windows Phone 7 development with this invaluable reference.

View the original article here

Rails: an introduction

Rails: an introduction - MySQL tutorial - developer Fusion Developer Fusion - The global developer community for .NET and Java programmers .NET Java Open Source Mobile Database SQL Microsoft Access MySQL Oracle SQL Server Architecture RIA & Web Toolbox MySQL News Tutorials Code Training User Groups Books Podcasts Forum Jobs Home Database MySQL Tutorials Rails: an introduction 02 Nov 2010 | by Kevin Jones | Filed in Comments PDF Ruby Test Driven Development C# C++ Agile This article was originally published in VSJ, which is now part of Developer Fusion.

Rails is a Ruby-based framework for building Model View Controller (MVC) applications. Ruby itself is a language that has generated a lot of interest in the last few years, not least because of Rails. Rails was initially created from work done by David Heinemeier Hansson for a company called 37signals. DHH (as he is known) was working on a number of web sites and Rails emerged as a framework from the internal work done building web applications. Internally Rails supports many of the principles of agile software development such as Test Driven Development (TDD), “You Aint’ Going to Need It” (YAGNI) and “Do not Repeat Yourself” (DRY), and is said by many in the Rails community to be ‘opinionated software’, i.e. it has its own opinion about how things should be done, and if you don’t like it, tough!

In this article I’ll introduce Rails and look at certain aspects of using it, such as its support for TDD and database access. Mac OSX seems to be the system of choice for building Rails applications and that’s what I’ll use for this article, during which I’ll talk about starting development of a blogging application (RBlog), which is currently a work in progress.Start at the beginning. Go on to the end and then stop, said the Red QueenRails tries to make many common tasks simple. To help do this Rails has a set of scripts that can be run to generate code. The scripts can generate the initial structure of the application and the classes and software needed in the application as we go along. These scripts are run from within a console window.

To start a Rails app I need to run the code generator to create the application structure. To do this I’ll start up a terminal and, making sure I’m in the right directory, call:rails rblogThis script will create a new Rails application for me. Running the script gives me the well known (well known if you do Rails!) directory structure of:appconfigdbdocliblogpublicscripttesttmpvendorThe above structure is common to all Rails applications and is part of the opinionated nature of Rails. For now I care about the following directories:86dd4058eef8d9b6dca0bedb488bde50The first thing I want to do once I’ve created the application is to execute it to see what we have. So once the application has been created I can fire up another terminal (I usually have at least two terminals open and sometimes three, one for my commands, one for the server and another to see the log file). In the new terminal window change the project directory and run the server with the command ‘script/server’. This starts the server on port 3000, the default. The server I’m using here is Mongrel which is the default server built into the Rails download, there are other servers you can use such as WEBrick and if course it’s possible to run production servers behind Apache. There’s plenty of discussion on these servers out on the web so I won’t go into the differences here.

Once the server is running you can point your browser at:http://localhost:3000…and you should see something like Figure 1.

Figure 1

This is good. We have a running application. It doesn’t look like it does a lot but it does at least work.

The next step is to create the database. For the database I’m going to use MySql, which has long been the database of choice for Rails applications, although the default database in the current release is SQLite, which is fine for development and testing, but not for production. Rails, like other environments, abstracts away the database access. The first step to doing this is to configure rails to use the specific database engine in use. This configuration is in the database.yml (yml files are YAML, which stands for YAML Ain’t a Markup Language) file in the config directory. I edit the file to look like this:development:adapter: mysqlencoding: utf8database: rblog_developmentusername: rootpassword:socket: /tmp/mysql.sockThis points the application at a database called rblog_development using the root user with no password. I can then add similar entries for the test and production databases. Once that is done I create the development database by running:mysqladmin -u root create rblog_developmentThis creates the “rblog_development” database.

Now that all the necessary structure is in place I can create the first controllers and models. What do I know about the blog? I know it’s going to have users, users can have blogs and blogs will have entries and comments. There may be more things eventually, such as tags, categories, pingbacks etc., but for now that’s enough. This means that at the moment I need to create models for users, blogs and blogentries; I also need to create controllers for these resources.

For the users model the user will have an email address and password, the password will be stored as a hash and will be salted (this is stolen more or less directly from the Agile Web Development With Rails book written by Dave Thomas et al, published by the Pragmatic Programmers). A user will have a name that can be displayed on comments or on a blog and users may also own blogs. For now I’m going to limit this to one blog per user, but in the future this may expand to multiple blogs.

As I mentioned above, Rails has a bunch of scripts that will generate the base code for me. In this case I need to generate a ‘scaffold’. The scaffold gives me the outline of the resources I want to use. To create the scaffold I need to run the ‘generate’ script, like so:script/generate scaffold useremail:string hashed_password:stringname:string blog_id:integerThis will create the model, the controller and the view for the User resource as well as the database migration. I’ll take a look at the details in a moment. I can then do the same for blogs and blogentries:script/generate scaffold blogtitle:string sub_title:stringowner_id:integer admin:booleanscript/generate scaffold blog_entrytitle:string entry:textauthor_id:integerNotice that I’m using singular names for the model components, so user, blog and blog_entry. This is a standard Rails naming convention, the singular names map onto plural database table names. So a User model maps onto a Users table (each row in the table will contain a single User, so the naming convention makes sense).

The generated blog entry code looks like this:The modelclass BlogEntry < ActiveRecord::BaseendThe controller:class BlogEntriesController < ApplicationController # GET /blog_entries # GET /blog_entries.xml def index end # GET /blog_entries/1 # GET /blog_entries/1.xml def showetc...The migration:class CreateBlogEntries < ActiveRecord::Migration def self.up create_table :blog_entries do |t| t.string :title t.text :entry t.integer :author_id t.timestamps end end def self.down drop_table :blog_entries endend

Notice that the BlogEntry model contains no data members, they are defined in the migration. The migration contains the code that will set-up and tear down the database, in this case creating a Blog_Entries table with title, entry and author_id column. The table will also contain a created_at and updated_a column, added by the t.timestamps entry. And finally the table will contain an Id column that will be the primary key for this table. So I get some things for free (the Id), and again this points up the opinionated nature of Rails. There are also a number of view files created for the Blog_Entries type which I won’t show here. The generated code for the other resources follows a similar pattern.

ActiveRecord and database access

One of the driving forces of Rails is to make things easier for developers. It does this partly by taking decisions out of developers’ hands. It’s an ‘opinionated’ framework after all, and one of the opinions it has is on the pattern to use for database access. Its choice in this case is the ‘active record’ pattern. Within Ruby, ActiveRecord is all about providing database access for our application.

Rails has an ActiveRecord module and the model classes all derive from ActiveRecord::Base, for example:BlogEntry < ActiveRecord::BaseIt is this module that provides the active record support for the framework.

Like much of the rest of Rails, ActiveRecord follows naming conventions. Here for example the BlogEntry class represents a row in the blog_entries table. How does this happen?

Previously I ran this script:script/generate scaffold blog_entry ...This script created two files, the file with the model class BlogEntry definition and a “migration”. The migrations are “scripts” that help create and mange the database definitions, essentially they are DDL for Rails. Migrations are used to both set up and tear down databases. The files contain class definitions that specify the steps to take when managing the database. Migrations are timestamped so that it is easy to apply migrations in the correct order and to rollback those migrations in reverse order if needs be. The migrations live in the db/migrate directory. Currently there are four migrations in there:20080925064318_create_sessions.rb20080925065056_create_blogs.rb20080925064319_create_users.rb20080925065210_create_blog_entries.rbThe first is a fairly standard Rails migration that creates the session tables (run rake db:sessions:create to create this), the others are specific to this application. Each migration has a date-time as part of the file name and it’s this name that determines the order in which the migrations are run. The 20080925065210_create_blog_entries.rb looks like thisclass CreateBlogEntries < ActiveRecord::Migration def self.up create_table :blog_entries do |t| t.string :title, :null => false t.text :entry, :null => false t.integer :author_id, :null => false t.timestamps end enddef self.down drop_table :blog_entries endend

This is similar to the code shown previously but with constraints added to three of the columns to prevent them taking on NULL values. I added these constraints by hand editing the file.

So the migration is a class that derives from ActiveRecord::Migration and provides two class methods (static methods to C#/C++ folks), up and down (it’s the “self” that indicates that these are class methods and not instance methods). You can run the migration from the command line by using the Rake command:rake db:migrate

Rake is Ruby’s equivalent of make, ant, nant or MSBuild.

This runs any migrations that have not yet been run. How does it know which migrations to run? There is a database table that holds the information about the migrations that have been run. I can see this table in MySQL by running the following commands:$ mysql -u rootmysql> use rblog_developmentmysql> show tables;…which show something like:+-----------------------------+| Tables_in_rblog_development |+-----------------------------+| blog_entries || blogs || schema_migrations || sessions || users |+-----------------------------+…and running:mysql> select * from schema_migrations;+----------------+| version |+----------------+| 20080923152418 || 20080923152427 || 20080923152435 || 20080925064318 || 20080925064319 || 20080925065056 || 20080925065210 |+----------------+

…shows the above rows on my machine as I write this article. Notice that the last entry in the table matches the datetime portion of the name of the last migration file.

When a migration is run (assuming it has not yet been added to the database), then the self.up method is executed. This method creates or modifies database entries. In the case of the blog_entries migration it creates the table and adds the six columns defined in the migration, remember that the id and timestamps are also added.

Again, running mysql shows this:mysql> show create table blog_entries;+--------------+---------------------+| Table | Create Table |+--------------+---------------------+| blog_entries | CREATE TABLE 'blog_entries' ('id' int(11) NOT NULL auto_increment,'title' varchar(255) NOT NULL,'entry' text NOT NULL,'author_id' int(11) NOT NULL,'created_at' datetime default NULL,'updated_at' datetime default NULL,PRIMARY KEY ('id')) ENGINE=InnoDB DEFAULTCHARSET=latin1 |+--------------+--------------------+

Notice that timestamps turns into two columns, and that an id column has been added as a primary key.

A migration can also be rolled back. Running rake db:migrate rollback will rollback the last migration, or a specific version can be specified. For example rake db:migrate VERSION=20080925065056

Running the migrations this way runs them in reverse order up to the specified migration, on the way the self.down method of each migration is called. For the blog_entries migration would drop the table. The down method should undo whatever the up method did!

One of the interesting (and sometimes frustrating) things about Rails is the way the migrations and the models work together. Running the script/generate scaffold blog_entry creates two files, the migration and the model. Looking in the model file there is… nothing, just the class definition. The knowledge about the members of this class is in the migrations. This takes DRY (Do Not Repeat Yourself) to the limit but it can mean looking in several files (there maybe more than one migration per model) to find everything that the class uses. If the migrations get too “spread out”, i.e. there are three or more migrations with modifications to one table, then it is worth amalgamating those migrations into one file.

Once you have the database in place it is a trivial exercise to use them, and again Rails comes into its own here. ActiveRecord provides finder methods that can be used to find entries in a table based on the primary key, and ActiveRecord also extends the base find methods available dynamically. I can explore this behaviour outside of a browser, which is a great way to do testing.

From a terminal I can open a Ruby console like this:

$ script/consoleLoading development environment (Rails 2.1.0)>>

…from here I can then execute Ruby code. I can create a new blog_entry and add it to the database, something like this:

>> be = BlogEntry.new=> #>> be.title='Hello World'=> "Hello World">> be.entry='My first entry'=> "My first entry">> be.author_id=1=> 1>> be.save!=> true

In this case I create a new BlogEntry object, set its fields then save it to the database. The call to save! throws an exception if something goes wrong. In this case the code is written entirely in the console, but the same code would be run from the within the application itself.

Barely scratching the surface

In this article I’ve barely scratched the surface of Ruby or Rails. I haven’t touched on the controller’s support for REST, how resources are created and destroyed, how tests are run. In a follow-up article I’ll look at these topics.

You might also like... Comments About the author Kevin Jones

Kevin Jones has been involved in software development and design for more years than he cares to remember, and has been involved in training and consultancy since 1990. He is the co-author of Se... Interested in writing for us? Find out more.

MySQL tutorials Productivity against all odds Unit testing in Ruby ActiveRecord for Ruby and Rails Rails: an introduction MySQL books Coding for Penetration Testers: Building Better Tools

Tools used for penetration testing are often purchased or downloaded from the Internet. Each tool is based on a programming language such as Perl, Python, or Ruby. If a penetration tester wants to extend, augment, or change the functionality of a too...

MySQL forum discussion Storing and retrieving dates from MS Access using C# by faith_akp (10 replies) How can i convert image type to bitmap type in c#.net by marrisazhang (2 replies) mysql database by andrew011 (2 replies) How to Make Default Button? by annaharris (16 replies) C# application of windows media player. by hosseinmohammadimehr (2 replies) MySQL podcasts .NET Rocks: Amir Rajan Does Frictionless Development with Oak Published 3 months ago, running time 0h53m

Carl and Richard talk to Amir Rajan about his Oak project on GitHub. Amir discusses his approach to building Single Page Applications (SPA) using an array of open source tools including Rake (from the Ruby stack), nSpec, Canopy, Growl and more. The conversation digs into how C# fits into the equa.

MySQL jobs Technical Lead – Ruby on Rails Wimdu GmbH in Berlin, Germany
Ruby on Rails Developer Wimdu GmbH in Berlin, Germany
Mobile App and API Developer Whitepages.com in Seattle, United States
Ruby/Ruby on Rails Developer Stratajet Ltd in London, United Kingdom
Based on experience MySQL events Jul 20 ChicagoRuby: Elmhurst - How Do I Build... ? Chicago, United States

The "How Do I Build...?" format is somewhere between a hack night and a presentation.The key question: "How do I build [X] in Ruby or Rails?" We might talk about the best shopping cart or calendar or whatever for Rails. We might talk about the best way to do database maintenance with Ruby, or the best tools for organizing Ruby or Rails development.Every ChicagoRuby member is invited to drive.

Contribute

Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Web Development ASP.NET Quickstart Programming news Java programming ASP.NET tutorials C# programming Developer Jobs ASP.NET Jobs Java Jobs Developer Jobs Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

Join us Sign in Pakistan Username Password Cancel “UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity.” - Dennis Ritchie Send feedback Blog About us Contact us Advertise © 1999-2013 Developer Fusion Ltd Managed hosting by Everycity

View the original article here

Ruby on Rails 3 Tutorial: Learn Rails by Example (Addison-Wesley Professional Ruby Series

The Ruby on Rails 3 Tutorial: Learn Rails by Example by Michael Hartl has become a must read for developers learning how to build Rails apps.

—Peter Cooper, editor of Ruby Inside

Learn Rails 3 Development Hands-On, from a World-Class Expert

Using Rails 3, developers can build web applications of exceptional elegance and power. Although its remarkable capabilities have made Ruby on Rails one of the world’s most popular web development frameworks, it can be challenging to learn and use. Ruby on Rails™ 3 Tutorialis the solution. Leading Rails developer Michael Hartl teaches Rails 3 by guiding you through the development of your own complete sample application using the latest techniques in Rails web development.

Drawing on his experience building RailsSpace, Insoshi, and other sophisticated Rails applications, Hartl illuminates all facets of design and implementation—including powerful new techniques that simplify and accelerate development.

You’ll find integrated tutorials not only for Rails, but also for the essential Ruby, HTML, CSS, JavaScript, and SQL skills you’ll need when developing web applications. Hartl explains how each new technique solves a real-world problem and demonstrates it with bite-sized code that’s simple enough to understand, yet novel enough to be useful. Whatever your previous web development experience, this book will guide you to true Rails mastery.

This book will help you

Install and set up your Rails development environmentGo beyond generated code to truly understand how to build Rails applications from scratch Learn Test Driven Development (TDD) with RSpecEffectively use the Model-View-Controller (MVC) pattern Structure applications using the REST architectureBuild static pages and transform them into dynamic onesMaster the Ruby programming skills all Rails developers needDefine high-quality site layouts and data modelsImplement registration and authentication systems, including validation and secure passwordsUpdate, display, and delete usersAdd social features and microblogging, including an introduction to AjaxRecord version changes with Git and share code at GitHubSimplify application deployment with Heroku

View the original article here

Scripted GUI Testing with Ruby

Ian Dees talks about his new book on testing GUI applications. His company uses Ruby to test handheld devices. Sponsor

Ian Dees talks about his new book on testing GUI applications. His company uses Ruby to test handheld devices.

View the original article here

Software Architect programme announced

Software Architect programme announced - TDD news - developer Fusion Developer Fusion - The global developer community for .NET and Java programmers .NET Java Open Source Mobile Database Architecture Agile Test Driven Development CQRS nTier Patterns SOA RIA & Web Toolbox Test Driven Development News Tutorials Code Training User Groups Books Podcasts Forum Jobs Home Architecture Test Driven Development News Software Architect programme announced By Mike James, published on 31 May 2009 | Filed in Comments PDF Test Driven Development This article was originally published in VSJ, which is now part of Developer Fusion. The programme for the third annual Software Architect conference, which takes place in London at the end of September, has been announced. The three-day event incorporates a two-day, five-track conference, with an optional pre-conference day of intensive workshops, which can be booked independently or as part of an all-inclusive package.

The event takes place this year at the Royal College of Physicians, and covers a wide range of key topics, including unit testing, design patterns, REST, lean software architecture, NET 4.0, modelling, architecting for multi-core, emergent design, and many others.

For the first time this year there are sessions which focus in depth on specific real-world projects, including one on the design choices made in developing the MorganDirect trading platform for J.P.Morgan, and another describing how a new architectural approach was devised for Confused.com’s web site.

Significant ‘early-bird’ savings are currently on offer, full details of which are available on the conference web site.

You might also like... Comments TDD news Automated hardware testing of Surface with Patty the robot Software Architect programme announced JetBrains releases TeamCity 4.5 TDD books Experiences of Test Automation: Case Studies of Software Test Automation

Software test automation has moved beyond a luxury to become a necessity. Applications and systems have grown ever larger and more complex, and manual testing simply cannot keep up. As technology changes, and more organizations move into agile develo...

TDD jobs RoR Developer @ Wimdu Wimdu GmbH in Berlin, Germany
Contribute

Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Web Development ASP.NET Quickstart Programming news Java programming ASP.NET tutorials C# programming Developer Jobs ASP.NET Jobs Java Jobs Developer Jobs Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

Join us Sign in Pakistan Username Password Cancel “Nine people can't make a baby in a month.” - Fred Brooks Send feedback Blog About us Contact us Advertise © 1999-2013 Developer Fusion Ltd Managed hosting by Everycity

View the original article here

Software Architect programme announced

Software Architect programme announced - TDD news - developer Fusion Developer Fusion - The global developer community for .NET and Java programmers .NET Java Open Source Mobile Database Architecture Agile Test Driven Development CQRS nTier Patterns SOA RIA & Web Toolbox Test Driven Development News Tutorials Code Training User Groups Books Podcasts Forum Jobs Home Architecture Test Driven Development News Software Architect programme announced By Mike James, published on 31 May 2009 | Filed in Comments PDF Test Driven Development This article was originally published in VSJ, which is now part of Developer Fusion. The programme for the third annual Software Architect conference, which takes place in London at the end of September, has been announced. The three-day event incorporates a two-day, five-track conference, with an optional pre-conference day of intensive workshops, which can be booked independently or as part of an all-inclusive package.

The event takes place this year at the Royal College of Physicians, and covers a wide range of key topics, including unit testing, design patterns, REST, lean software architecture, NET 4.0, modelling, architecting for multi-core, emergent design, and many others.

For the first time this year there are sessions which focus in depth on specific real-world projects, including one on the design choices made in developing the MorganDirect trading platform for J.P.Morgan, and another describing how a new architectural approach was devised for Confused.com’s web site.

Significant ‘early-bird’ savings are currently on offer, full details of which are available on the conference web site.

You might also like... Comments TDD news Automated hardware testing of Surface with Patty the robot Software Architect programme announced JetBrains releases TeamCity 4.5 TDD books Experiences of Test Automation: Case Studies of Software Test Automation

Software test automation has moved beyond a luxury to become a necessity. Applications and systems have grown ever larger and more complex, and manual testing simply cannot keep up. As technology changes, and more organizations move into agile develo...

TDD jobs RoR Developer @ Wimdu Wimdu GmbH in Berlin, Germany
Contribute

Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Web Development ASP.NET Quickstart Programming news Java programming ASP.NET tutorials C# programming Developer Jobs ASP.NET Jobs Java Jobs Developer Jobs Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

Join us Sign in Pakistan Username Password Cancel “Nine people can't make a baby in a month.” - Fred Brooks Send feedback Blog About us Contact us Advertise © 1999-2013 Developer Fusion Ltd Managed hosting by Everycity

View the original article here

Test Driven Development Part Deux--The Rest Of The Story

In Episode 23, Rob, Nick, and Brett catch up with SharePoint MVPs Andrew Woodward and Eric Shupps to FINALLY get the answers on Test Driven Development on SharePoint.

If you haven't seen the infamous TDD videos that we did at the MVP summit, go watch them NOW as it will give you a great background on why this show came to be. 

The following topics are covered in this show:

What is TDDHow does TDD and Agile relate to SharePointWhy TDD and SharePointPros and Cons of TDD

Click here to download the show!

View the original article here

Testing In An Agile World: The Heart Of A Developer

I often talk about agile development and agile engineering practices. I talk about Test Driven Design and ponder the possibility of writing bug free programs. I make a case that for the most part, bugs can be kept out of customer’s hands by a good agile development team.

After saying all this, the questions start:

“Are you saying that testers are going to be out of a job?”,
"With all these unit tests being written by developers, what will be left for testers to do?”
or (more insidiously) “So I’ll be able to fire all my testers?”

My short answer is, “No, lots of stuff, and No.”

My not quite as short answer is, “In an agile world, the roles that testers play will change, and it will require significant mindset changes from everyone in the development cycle to fully benefit from these role changes”

But first a little background…

When I started out as a developer, I literally worked in a guy’s kitchen writing handicapping software for football and basketball. I was young, enthusiastic and my skills were barely enough to keep me in front of his change requests.

When he would ask for changes, I would make those changes and bugs would start to appear in other places in the code. In my world, bug reports came with sad disappointment. It was as if my boss knew that I was a better coder, than my code made me appear to be. It became very important for me to find bugs before he did, and so I started learning how to do testing. As I got better at checking my code, fewer bugs escaped me and I got fewer disappointed looks.

While I never got to the point where bugs did not (occasionally) slip by both him and me, they got to be a rare occurrence. We eventually went on to win awards in Las Vegas for that product.

A few years later…

I was working in a different shop and went in to see our lead tester about a requirements issue. (Ted was both our lead tester, and a functional product owner.)

“Hey Ted” I said as I walked in, “I’ve got a question for you.”
“You are just the person I wanted to see,” he said, “I found a bug in your module”
“Cool, show me.”
He then proceeded to use my module to crash the application.
I smiled and said, “Awesome. Thanks, I’ll go fix that.”

And then Ted said something to me that I still cherish, 16 years later, “And that’s why we like finding your bugs, first, it’s rare when one bad gets by you, and second, you are always so happy to see them.”

I said, “I’m just glad you found it and not a customer.”
His response was, “Not everyone looks at it the way you. One of our guys feels like we are picking on him personally when we find one of his bugs.”

I didn’t know what to say to that.

At that point I was still young and believed that if you were a good enough developer, testers were a luxury . A luxury to be cherished and enjoyed, but still a luxury.

What a load of conceit.

The problem was that I had to become a decent tester. What I didn’t know then was that I wasn’t a great tester and that I would probably never be a great tester.

This mindset was summed up for me a few years later when I had the privilege of working with some great testers. Someone at that shop put it this way.

“A great tester, has the heart of a developer…”

The person who told me this paused and let me think about the implications of that statement. But he didn’t wait too long before delivering the punch line

“…in a jar on their desk.”

In a grossly oversimplified light:  developers create, testers destroy.

You would think that this create and destroy dichotomy would prevent developers and testers from working together in a partnership. And if testing and development are kept from each other they don’t become partners, they become competitors. Not always, but often enough for it to be an anti-pattern that emerges in a shop that is heavily silo’ed.

Factors that cause friction in a silo’ed situation

Silos that have different managers and non-aligned incentives Pay testers based on # of bugs found Pay developers based on # of features released to market An attitude that developers create value and testers hinder productivity Managers battling for turf Unclear company mission A gotcha mentality (when a bug is found by a customer, whoever can shift the blame to the other department fastest, wins) Quality gates and processes, put in place because of past company quality failures Testers acting as the last bastion of quality when they believe developers are willing to use the end-customers as a testing department.

This is a natural pattern that will need to change. Testers have gotten used to being the last bastion of quality and will sometimes fight to the death that the product can't be released tomorrow, until the spelling mistake on a button is fixed, while at the same time insisting that they (the testing department) must have 2 weeks to test and certify the product after the change of spelling has been implemented.

There are no promises, but here are some possibilities.

New builds that install properly every timeHaving your test plan roughed out, before the developers start writing code.People saying nice things about the testing department, like, “Our testers found a design bug that could have cost us $50,000 if we had had to fix out in the field”Never having to do another repetitive, brain dead testing runBeing able to focus on the fun stuff: stress testing, load testing, (or even better) having the developers delighted when you bring back a flock of bugs from an exploratory destructive testing binge.Being asked to accompany the account manager on a trip to the client site in order to assist in requirements gathering.

Of course, if you read that list and start thinking the following…

But what if I like repetitive brain dead testing runs? But what if I don’t enjoy what you call the fun stuff?But what if I don’t want to go to client site?

Well, I said that going agile was going to require changes to everyone’s mindsets, that includes testing.

Testers need be able to do more that test, they need to be able to teach how they do what they do.

QA people who just do process also need to be able to test.Developers need to understand that QA only uncovers the bugs created by developersOther employees have to stop assuming that the test department is just a developer training ground.Other employees have to stop assuming that the test department is filled with failed developers.

A quick note for those of you who think this list is silly: I invite you to buy a cup of coffee for a tester with more than 5 years of testing experience and ask them to tell you stories related to things on this list. There’s a prize for the best story left in the comments below.

Moving a team into an agile style of development requires a change in mindset and work practices from all involved, but QA folks should find an increased importance and a change in the perceived attitude to their role from their colleagues.

Developers who don’t already, will need to learn to ask themselves the question, “how is someone going to break my code?” (Testers can teach developers to think a little bit more like a user.)Testers can get involved in the design process and have their test plans roughed out before development begins. This can lead to better designs because in many waterfall shops, the first time QA sees the program is after the project has entered the “test-phase.” At this point it is too late to do anything about possible design flaws.Testers will also have to learn to be partners in the development process. I have seen testers who didn't want to help developers. The reason was they needed to find bugs to justify their position, and how can they do that if the developers kill all the bugs before it gets to them? QA managers will sometimes fight an agile adoption because they believe that it will threaten their job. This can be a valid fear in certain organizations.

The bottom line is that testing in the agile world will be different but testers will still be needed. Testers will find themselves with more recognition and more responsibility.

And my short answer is still, “No, lots of stuff, and No”

View the original article here

Top 5 Visual Studio 2010 Features

Think you're a DevGuru? Put yourself up against the clock and see if you can become a DevGuru and reach the top of the leader board. Up for grabs is a top of the range coffee machine to keep you coding through the night, as well copies of Microsoft Visual Studio Professional Edition. Enter here.

Visual Studio includes a vast number of windows – the Solution Explorer, the Properties window, the Class Viewer, and so forth. Visual Studio 2008 allows developers to move, resize, and pin these windows inside Visual Studio’s top-level window, or to float them and move them anywhere on the desktop, including to a secondary monitor. With Visual Studio 2010 you can also float code and designer windows and move them outside of the top-level window. Using this feature you can examine multiple files at once across multiple monitors.

Visual Studio 2010’s IntelliSense has been drastically improved. For starters, it’s noticeably faster than in previous versions. It’s also easier to find the type or member you’re looking for, as IntelliSense now searches for any matches that contain the text you enter rather than limiting the results to those terms that match directly.

For example, typing in Console.Window displays eight matches. As you’d expect, the list includes those members that start with the word Window – WindowHeight, WindowLeft, WindowTop, and WindowWidth – but it also includes those members that include the word Window – LargestWindowHeight, LargestWindowWidth, SetWindowPosition, and SetWindowSize. Additionally, you can search for Pascal cased types and members by entering just the capital letters in the type or member name. Entering Console.WH displays two properties: LargestWindowHeight and WindowHeight.

Programming methodologies like Test Driven Development (TDD) encourage writing code using a consume-first pattern. Before creating a class or adding a new method, developers first write a unit test. If you practice TDD or routinely write stub code that references classes or members that you’ve not yet created then you’re well aware of one of IntelliSense’s biggest annoyances – it overwrites any non-existent type or member names you type with the closest known match. For example, say that you start to write a unit test for a not yet created class named Cons.

When you type in the text Cons Visual Studio will suggest Console from the IntelliSense drop-down. When you enter a period or a left parenthesis, Visual Studio replaces what you had entered – Cons – with the selected type in the IntelliSense drop-down – Console. How annoying!

Visual Studio 2010’s IntelliSense makes it easier to practice consume-first development. You can toggle IntelliSense between its standard mode and the consume-first mode from the Edit menu’s IntelliSense submenu, or by using the keyboard shortcut Ctrl+Alt+Space. When using consume-first mode, IntelliSense will not overwrite unknown type or member names. What’s more, after entering the new type or method name you can use Visual Studio’s built-in refactoring tools to create the new class, method, or property with a single click of the mouse.

When debugging, Visual Studio displays the name and value of a variable when you hover your mouse over it. In Visual Studio 2010 this information can be pinned to the same window the code you are debugging appears in. Pinning a variable allows you to observe how the variable’s value changes as you step through the code. You can also add comments to the pinned watch variable, and Visual Studio remembers and reloads these comments and the pinned watch variables the next time you launch the debugger.

Visual Studio has long supported searches across documents in a project or Solution, but such searches were limited to specific substrings and returned no contextual information. Visual Studio 2010 greatly improves the search experience with the Navigate To window, which is accessible from the Edit menu. From the Navigate To window you can search across your entire Solution for files, types, methods, properties, fields, and events. Much like IntelliSense, the Navigate To window searches for any matching types or members that contain the string you enter. Likewise, you can search for Pascal cased types and members by entering just the capital letters.

The Navigate To window displays each matching result with an icon that indicates whether the match is a file, a type, a class, a property, et cetera. Selecting a result lists the project name, filename, and line number where it appears, and double-clicking a result opens the file at the appropriate line of code.

Each new version of the .NET Framework introduces dozens of new controls to the Toolbox, but finding a control in the Toolbox is now easier than ever. Simply select the Toolbox window with your mouse (or hit Ctrl+W, X from your keyboard) and then start typing the name of the control you want to find. Visual Studio will select the first control it finds that starts with your input; toggle through multiple matches using the tab key.

Think you're a DevGuru? Put yourself up against the clock and see if you can become a DevGuru and reach the top of the leader board. Up for grabs is a top of the range coffee machine to keep you coding through the night, as well copies of Microsoft Visual Studio Professional Edition. Enter here.

View the original article here

Unit testing in Ruby

Unit testing in Ruby - Ruby tutorial - developer Fusion Developer Fusion - The global developer community for .NET and Java programmers .NET Java Open Source C++ Django PHP Python Ruby Linux OpenGL Mobile Database Architecture RIA & Web Toolbox Ruby News Tutorials Training User Groups Books Podcasts Forum Jobs Home Open Source Ruby Tutorials Unit testing in Ruby 04 Oct 2010 | by Kevin Jones | Filed in Comments PDF Ruby Test Driven Development This article was originally published in VSJ, which is now part of Developer Fusion.

Over the last decade or so developers have recognised how important testing in general and unit testing in particular have become. There are unit testing frameworks for all the major languages and in some cases more than one framework. Ruby is no exception. In fact, as Ruby is a dynamic language unit testing is even more important. In static languages the compiler will find many errors. With dynamically typed languages such as Ruby there is no compiler around to check the code, so it is even more important that unit tests are in place to help verify the code’s correctness.

Testing in Ruby?

Ruby offers a couple of test frameworks, among these are Test::Unit which is available in Ruby 1.8 and MiniTest::Unit available in Ruby 1.9. These are very similar, and tests written with Test::Unit will mostly work with MiniTest::Unit. The primary differences are that MiniTest drops the GUI tools that Test::Unit contained and MiniTest::Unit has replaced Test::Unit’s assert_not functions with corresponding refute functions. I’m going to use Test::Unit as most people are still using Ruby 1.8.

To illustrate some of the concepts we should first have something to test. In respect of all the many articles and training classes on testing we’ll use a calculator as the first example. Our initial calculator class will be simple:

class Calc def add endend

…and we can now set about testing it.

Our test class has to use the Test::Unit classes and so should require them. The test class also needs to derive from TestCase, this will allow Test::Unit to bring in the bits it needs to run the tests.

Initially we’ll place the test code in the same directory as the code under test (we’ll change this in a few minutes), this means our test code will look like this:

require 'test/unit'require 'calc'class TestAdd < Test::Unit::TestCase def test_add calc = Calc.new expected = calc.add 3,2 assert_equal expected, 5 endend

There are several things to note here. As I mentioned above we require ‘test/unit’ to bring in the testing code and we then derive from TestCase, this gives us access to the asserts and other helpers in Test::Unit. The name of the test method starts with ‘test’, this is how the test framework identifies this as being a test. In here we create an instance of a calculator and call its add method, all standard Ruby. Then we use one of the Unit::Test helpers, assert_equal, this does exactly what it says on the tin and checks the equality of the two values. We can run this from a shell:

$ ruby test_add.rbLoaded suite test_addStartedFFinished in 0.01038 seconds. 1) Failure:test_add(TestAdd) [test_add.rb:10]: expected but was<5>.1 tests, 1 assertions, 1 failures, 0 errors

…and of course the test fails (remember our calculator currently does nothing), so we fix the calculator and run the test again:

Loaded suite test_addStarted.Finished in 0.000319 seconds.1 tests, 1 assertions, 0 failures, 0 errors

That’s much better. Notice that in keeping with other test frameworks in other languages the output of the tests are simple, a ‘.’ for each test that passes meaning we can scan the output quickly and see that everything passes (or something fails) very easily. We can add a second test to see this, something like:

def test_add_bigint calc = Calc.new val = calc.add 1000000000,1000000000 assert_equal val, 2000000000endLoaded suite test_addStarted..Finished in 0.000407 seconds.2 tests, 2 assertions, 0 failures, 0 errors

Note the two dots, so we have an easy-to-read result.

We have an issue at the moment with the way the code is structured in terms of the layout on disk. The tests live in the same directory as the code under test. While this works, as we see above, it’s far from ideal. How do we know which is the test code and which is the system code? When we come to ship we probably do not want to ship the test code along with the system code. Because of this it’s good to separate the code into different directories. The simplest approach is to create two directories – one for the application (app) and one for the tests (test), so we end up with a structure that looks like this:

root|-- app|-- test

…where ‘root’ is some directory for this application, app contains the application code and test the testing code. When we do this we have to amend the test code so that it requires the app directory:

require 'test/unit'require 'app/calc'

The rest of the code stays the same.

To run the code we start a shell in the ‘root’ directory and tell Ruby where to find the test code, so something like:

$ ruby -I . test/test_add.rb

The -I . tells Ruby to include the current directory in it’s search path, if everything is OK we’ll see the same results as before, but now we have a good separation of the code from the tests.

Rails Testing

How does this fit with Rails? If you’ve used Rails or seen my previous articles you’ll know that a standard Rails application has a directory structure which looks something like:

root|-- app|-- controllers|-- ...|---- other stuff|-- test

…which is similar to what we have above. The test directory is further sub-divided into ‘unit’, ‘functional’ and ‘integration’ sub directories. These contain tests for different areas of your application. There is also a ‘fixtures’ sub directory that we’ll come back to. The unit directory will contain our unit tests, these will be the tests for the model classes in the Rails application. Functional tests will typically test our controllers and integration testing involves end-to-end testing.

When you create a model in Rails a unit test is created automatically. If the model is called user there will be a test file called user_test.rb, this will contain a class with one method:

def test_truthassert trueend

…which seems bizarre, assert that true is true!

The reason for this is to check that the test environment is configured correctly. You can run this test from the shell:

$ ruby -I test test/unit/user_test.rb

If you do this the test will fail with extreme prejudice! The reason being that the test environment has not been set up correctly. To run the model tests we must first have a test database, we’ve been using MySql so we fire up a MySql prompt and run (if this is our blog software):

create database blog_test;

But we’re still not quite there, we also have to migrate the current schema to the test database, from a shell run:

rake db:test:prepare

Once completed we can now run the test again, and this time it should succeed, true really is true!

You can also run a rake task to execute the unit tests:

rake test:units

This will execute the prepare task for you so if you use only this task there’s no need to manually initialise the test database. These tests work the same way as any other unit test, we will see a ‘.’ for a successful test and a failure message otherwise.

As an example our blog class looks like this:

class Blog < ActiveRecord::Base validates_presence_of :title validates_presence_of :sub_title validates_presence_of :nickname validates_uniqueness_of :nickname validates_presence_of :owner_id belongs_to :user, :foreign_key => "owner_id" has_many :blog_entries...end

…and we should test that validation code, so a test may look like:

class BlogTest < ActiveSupport::TestCase def test_blog_has_valid_fields blog = Blog.new assert !blog.valid? end...end

With unit tests we are typically testing models, and these models are backed by a database. For certain tests we would like the test database to contain specific data we could use. The way that is done in Rails is through the use of fixtures.

A fixture is a file, typically YAML but it could be CSV, that contains data for a table. A fixtures file may look like this:

blog_with_nickname: title: MyString sub_title: MyString nickname: kevin owner_id: 1blog_with_no_nickname: title: MyString sub_title: MyString owner_id: 2

The values ‘blogwithnickname’ and ‘blogwithno_nickname’ are the names of the fixtures. These names could be anything and in fact should be meaningful as we will use them in the test code. The name of the file containing the fixture must match the name of the database table, in this case ‘blogs’ and the formatting of the data in the fixture is significant. By default rails will load the fixtures associated with a unit test (convention over configuration again), but if necessary you can load specific fixtures as part of a test by including the line:

fixtures :blog

…at the top of the class containing the unit tests.

The data in the fixtures are loaded into the database before each test method is run, so each test starts with a clean database.

Within a test you reference a specific fixture by name, so within a test we could say something like:

blog = blogs(:blog_with_nickname)

…where blogs is the name of the file containing the fixture, this takes the name of the fixture as its argument. This will load the fixture from the database. We could have a simple test, something like this:

def test_valid_load blog = blogs(:blog_with_nickname) assert blog.valid?end

Fixtures are extremely flexible, for example you can also run Ruby code to create a fixture. Maybe you want to insert a number of rows into a table that are all very similar, we could write something like this:

<% 0.upto(9) do |i| %>blog_fixture_<%= i %>:nickname: nickname<%= i %>title: title<%= i %><% end %>

…to load ten entries.

Conclusion

Ruby like other programming languages provides support for unit testing. This is more important in dynamic languages as you have no compiler around to help check type correctness. Rails builds on Ruby’s test support and offers several useful features. Rails tests are separated into unit, integration and functional tests, use these as they are meant to be used, i.e. keep your unit tests short! Rails also provides the concept of test fixtures which help with testing models as they let us pre-load database tables for each test.

You might also like... Comments About the author Kevin Jones

Kevin Jones has been involved in software development and design for more years than he cares to remember, and has been involved in training and consultancy since 1990. He is the co-author of Se... Interested in writing for us? Find out more.

Ruby tutorials Productivity against all odds ActiveRecord for Ruby and Rails Rails: an introduction Creating a culture of quality: Part 1 Ruby books Coding for Penetration Testers: Building Better Tools

Tools used for penetration testing are often purchased or downloaded from the Internet. Each tool is based on a programming language such as Perl, Python, or Ruby. If a penetration tester wants to extend, augment, or change the functionality of a too...

Ruby podcasts .NET Rocks: Amir Rajan Does Frictionless Development with Oak Published 3 months ago, running time 0h53m

Carl and Richard talk to Amir Rajan about his Oak project on GitHub. Amir discusses his approach to building Single Page Applications (SPA) using an array of open source tools including Rake (from the Ruby stack), nSpec, Canopy, Growl and more. The conversation digs into how C# fits into the equa.

Ruby jobs Technical Lead – Ruby on Rails Wimdu GmbH in Berlin, Germany
Ruby on Rails Developer Wimdu GmbH in Berlin, Germany
Mobile App and API Developer Whitepages.com in Seattle, United States
Ruby/Ruby on Rails Developer Stratajet Ltd in London, United Kingdom
Based on experience Ruby events Jul 20 ChicagoRuby: Elmhurst - How Do I Build... ? Chicago, United States

The "How Do I Build...?" format is somewhere between a hack night and a presentation.The key question: "How do I build [X] in Ruby or Rails?" We might talk about the best shopping cart or calendar or whatever for Rails. We might talk about the best way to do database maintenance with Ruby, or the best tools for organizing Ruby or Rails development.Every ChicagoRuby member is invited to drive.

Contribute

Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Web Development ASP.NET Quickstart Programming news Java programming ASP.NET tutorials C# programming Developer Jobs ASP.NET Jobs Java Jobs Developer Jobs Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

Join us Sign in Pakistan Username Password Cancel “Java is to JavaScript what Car is to Carpet.” - Chris Heilmann Send feedback Blog About us Contact us Advertise © 1999-2013 Developer Fusion Ltd Managed hosting by Everycity

View the original article here