seen from United States
seen from Canada
seen from United States
seen from Singapore
seen from United States
seen from Canada
seen from Germany
seen from United Kingdom
seen from China
seen from United States
seen from United States
seen from United States
seen from United States
seen from China
seen from France
seen from Japan
seen from United States
seen from China
seen from Germany
seen from United States
Test Driven Development II
Test Driven Development II
Test-First way of thinking
A valuable software engineering practice, regardless of what methodology you are following.
Some companies can be apprehensive of developer testing, as they feel their testers should be the only ones carrying out tests.
Reasons why testing as soon as possible, even before development, is a great investment
Cost of fixing a bug after release Vs. finding bugs early on.
Hi…
View On WordPress
Test Driven Development
What is TDD?
A development process driven by the implementation of a test-first approach. The tests which are initially written will fail, then development begins, with the objective being to make the tests pass.
The benefits in the long-term are great, as you are laying the foundation for continuous integration. But it will require a lot of effort and focus in the short term, which can defer or…
View On WordPress
Thoughts on Continuous Integration
Ever since I first discovered [Continuous Integration](http://martinfowler.com/articles/continuousIntegration.html) I've been pushing for it in all the projects I've worked on. Most of the time we've had the luxury of introducing it at the start of a project. I really think you should be doing this as early as possible. As time moves on it will become harder and harder to introduce and this is especially true if you want to have a deployment step at the end of the process. Recently I've been working on a project where we so far have failed at getting a good continuous integration process up and running. Here's a few thoughts on what could have changed this. ## Structure of code and tests I've always been a fan of good structure in projects but when doing CI it is even more important. Set up a structure that allows you to build conventions around it. For instance you could have a Tests/Specs directory where you put all test projects. This would allow you to have your build script run all tests in that directory instead of having to specify each test project to run. A small but noticeable win. There's lot's more you could do but the point is that the structure of a code base matters! ## Treat your build as a first class citizen When you first get started with CI people tell you to value your build and to always make sure you have a working (green) build. You might be tempted to shrug your shoulders when the build breaks and say "not my code, not my problem" but this could not be further from the truth. It might not be your problem at that point in time but it will quickly become your problem when the code base starts to rot and it get's harder and harder to work with. No matter who is responsible for breaking the build, it should be the responsibility of the entire team to fix it! As soon as you stop caring about broken builds the value of having a CI-process goes from 100 to 0. ## Produce valuable artifacts Strive towards producing valuable artifacts as the result of a build and make them available for consumption by people and computers. If no one is dependent on the outcome of the build you won't have anyone yelling at you when the build stops working. This is essential! If no one cares enough to yell at you when it breaks, you will find it hard to get the resources to maintain a solid build process. The entire team, including product owners, should feel invested in your build process.
