|
|||
|
If you are like most test driven developers, you write automated tests for your software to get fast feedback about potential problems. Most of the tests you write will verify the functional behaviour of the software: When we call this function or press this button, the expected result is that value or that message. But . . . → Read More: Automated Performance Testing Have you ever faced the problem of writing unit tests which relies on textual test data? This is a classic issue where you usually end up putting the test data in a string variable or in an external file, depending on the amount of text. Neither of these options are particularly elegant. In this article . . . → Read More: CommentReader – Place your test data next to the test code This week I gave a presentation for a client, starting on Test and Behavior Driven Development. In this introduction we give a high level description of what it is and why it is useful for developers. Then we go into some details on stubs and mocks, test data, UI testing, SQL testing, JavaScript testing, web . . . → Read More: Test and Behavior Driven Development (TDD/BDD) One of the more popular ways of implementing web services is using REST and JSON, because it makes it easy to communicate with the web service from client side (or even server-side) JavaScript. In .NET we can use Windows Communication Foundation (WCF) to fairly easily implement JSON web services. We might consider using JavaScript to . . . → Read More: JsonClient – easy testing of JSON web services with NUnit I previously advised that you shouldn’t track bugs but rather fix them immediately. But not every issue reported as a bug should be treated as a bug in this sense. So how do we distinguish between a bug and a feature request? Issues are reported when the software is not behaving as expected. That expectation . . . → Read More: It’s not a bug, it’s a feature request I believe that it is often a good idea to have another set of eyes looking at the code I write. The questions and comments resulting from such a code review indicate its value: “It seems like you are missing a test case for this scenario, and I think the code will break on it” . . . → Read More: Lightweight code reviews using TortoiseSVN How do you sell an agile project? Most clients expect to buy software by time-and-material or by fixed-price-fixed scope contracts based on detailed requirements. These models cannot create a fertile environment for collaboration between client and vendor. We have touched upon this subject before, and today I am presenting on the topic for Bay Area . . . → Read More: Agile Contracts You want to shorten the time from idea to live. You want your team to develop faster. You want higher quality. In short: you want a high performance engineering team. This presentation is based on my experiences building high performance engineering teams, and focuses on the technical practices required. These practices centers around automation (build, . . . → Read More: High Performance Engineering Teams For agile development to work well, it is important to have many small stories and many small tasks. Alistair Cockburn has coined the evocative term elephant carpaccio for the process of dividing epics into minimal achievable stories and decomposing stories into minimal achievable tasks. I have previously blogged on this and yesterday I gave a . . . → Read More: Elephant Carpaccio Why are most software projects using a lot of different programming languages (e.g. SQL, Ruby, JavaScript, HTML, CSS)? Couldn’t we just use a single one? Wouldn’t that simplify everything? The issue is only partly a language issue. Doing everything (UI, business logic, data access) in C++, as I have often done for embedded projects doesn’t necessarily improve . . . → Read More: Always use the right tool for the job? |
|||
|
Copyright © 2012 ZeaLake - All Rights Reserved |
