Test Driven Dev

[Nick Parker]

Marc Clifton wrote:

I will say one thing though--I still can't write the test first. I have to write at least stubs for the actual code and then write the tests. It's because I do a lot of architecting when writing the code itself, as, ironically, I haven't found any decent code architecture/design tools--tools that don't hinder the creative process.

We recently had a break out discussion at our local user group over the topic of TDD, and this was one of things covered. The one thing I try to keep in mind is: "Describe what it needs to do, not how it needs to do it". You really have to change the way you think about writing code, if you can't do that, there will be major hurdles you will have to deal with later on. My 2 cents. :-)

- Nick Parker Microsoft MVP - Visual C#
My Blog | My Articles

[Judah Gabriel Himango]

feline_dracoform wrote:

was left with the impression that you had to setup a fake database for the tests, etc.

It depends. Here's how it goes: you write a test for a function. Then you realize that your function calls into something you don't want to test; maybe it calls into your data layer, or maybe it shows a dialog, etc. Since you're just testing this function, you want the test to be small and precise; you don't need to test your whole data layer; in fact, you want your test to execute instantly, you don't want it to even connect to your data layer. So here's where the mock objects come in; they let you mock your data layer or other resource you don't want this small test to encompass. Let's take a real example. You have a function called UpdateRecord that takes a patient record, changes the patient's last check-in time, and saves it to your data layer (which then saves it to the database or some other persistent storage).

public void UpdateRecord(Patient patientToUpdate)
{
patientToUpdate.LastCheckInTime = DateTime.Now;
dataLayer.SavePatient(patientToUpdate);
}

To really test this function, you'll want to verify that the date was set correctly and that it gets saved back to the data layer. How in the world can you do this, you might wonder. :) You can do this by refactoring your code to make it more modular and unit-testable; basically, making the function be more of a "unit" by itself, rather than relying on internals and variables. So let's first refactor the function so that we supply the date to the function, so that we can verify it's getting set correctly.

public void UpdateRecord(Patient patientToUpdate, DateTime updateTime)
{
patientToUpdate.LastCheckInTime = updateTime;
dataLayer.SavePatient(patientToUpdate);
}

With that, we can now write a simple test that verifies the patient's LastCheckInTime is set correctly.

[Test] // The Test attribute is an attribute in an NUnit assembly that lets unit testing frameworks know this function is a test function
public void UpdateRecordShouldSetCheckinTime()
{
Patient patient = new Patient();
DateTime checkinTime = DateTime.Now();
myFoo.UpdateRecord(patient, checkinTime);

// Assert class is a class in an NUnit assembly that allows a test to pass or fail based on some condition.
Assert.AreEqual(checkinTime, patient.LastCheckinTime, "The UpdateRecord method didn't set the last checkin time of the patient.");

}

Now, we also nee

[Judah Gabriel Himango]

Tests are for individual methods, yes. If the method depends on other objects, you plug in mock objects in place of those dependencies. This works; I actually did this for a big feature where we run multiple background threads which then report to a UI thread to update the UI. The whole feature was built for unit testing from the beginning, and I haven't had a single bug in it yet (not saying it won't have any bugs, but I feel pretty confident about the quality of the code). See my reply to feline_dracoform for more info.

Tech, life, family, faith: Give me a visit. I'm currently blogging about: Messianic Instrumentals (with audio) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango

[Jonas Hammarberg]

The real positive usage of TDD are when you need to change an implementation -- You will very quickly be informed of breaking any functionality (if the interface is tested throughly). But in your case, you do not have any real usage of it right now but if you are the maintainer in a couple of years down the road... You will curse your younger self for being soo narrow minded... I do see one drawback -- A TDD gives a false sense of security... Just because the test project doesn't break, doesn't say that everything works (as all to many seems to belive). rgds /Jonas

[Jonas Hammarberg]

Be nice, even the longest journey starts with a single step...

There's always someone bigger around the corner...

Usually it's my evil twin:cool:

[Sonrisante]

As soon as you're not the only one modifying it, and you need someone else to help you on modifications to some segement you wrote, or you need to pass it off to someone else entirely, the value of TDD would become very apparent. Modifying a line of code inside a function or procedure embedded within the bowels of a code body is always nerve-wracking, especially for someone who didn't write it to begin with (and in my case, I find it so even if I did write it but it was long enough ago that I can't downright remember all the ins and outs... after 15 years of developing applications, even the ones I did last year are hard to remember all the details of). With TDD, I modify the line that I *think* I need to modify, run the tests, and I'll see instantly whether I broke something elsewhere that I never would have imagined. In fact, I can use TDD to help me identify a better way to make a modification in these cases. The most difficult thing I find with TDD is deciding when is enough... it's tempting to test everything but that will never end. And you don't want to write tests in a way that will break everything if you have a design change. So it's as much of a design skill as writing the code itself. It's also a great confidence builder as you see that the tests are actually passing and continue to pass as you build your app.

[Siderite Zaqwedex]

I don't think TDD is making a lot of sense in a single developer situation, but rather with medium-big projects that can be changed over time by different devs. I mean, it might be straight forward for you to just build the application and tweak the bugs, but it might be difficult for someone else to tweak your app. Also tests are good in the refactoring process, you just run the suite of tests after you made the refactoring, to see if what you did to improve the readability of the code didn't change any functionality. ---------- Siderite

[Robert Vukovic]

Every body is talking about TDD but it seems that TOAD is valid only Java and .NET . What about GUI programing ? What about multithreading? What about C++ ? Can the TDD be used in these situations also ?

[Josh Smith]

John Simmons / outlaw programmer wrote:

35K lines? I'm sorry, but I'm laughing my ass off...

Good for you. :josh: My WPF Blog[^]

[schleprock]

Robert Vukovic wrote:

What about GUI programing ? What about multithreading? What about C++ ?

TDD can be applied to any programming language or situations. in my development world, we do gui, multithreading, C++, multiprocess. for the minor (play) programming of the original post (30K lines is barely getting started) with a single developer who does all aspects of product design, development and deployment, one can get away with not writing tests (though it is not a good idea). empirical testing is not a good way to test. it is inherently error prone (humans are very poor at repetitive tasks) and usually skips tests that the user simply “believes” cannot be broken (but invariably are broken). We’ve automated all of our testing (gui included) so that you are assured that the changes you have made work in the current source set. Without tests you cannot refactor with confidence (in fact according to “refactoring to patterns”, Kerievsky; you cannot refactor without a complete set of unit tests). TDD is also about writing the test before you write the code. The test should fail when you try to run the test (as the code “should not” exist yet), but if the test passes, then you don’t need to write any code. It also helps in finding those corner cases as you can write the crazy tests before you code and get an idea of how to solve the corner cases while you’re writing the main algorithm. This allows for you to provide a generic algorithm without all the “if..else” kludges for the corner cases. Asserts are not a testing methodology, they are a debugging methodology. Asserts are supposed to be used to test setup conditions and assumptions in the code. They are not a good tool for testing code. Automated unit and regression testing are the best way at this point. Formal proofs are the best method, in theory you would not even have to run tests if one could provide a formal proof of the application, but we’re a long way away from that (maybe never for complete applications). TDD is not a silver bullet (there are NO software silver bullets, see IEEE Queue, I think june ’06 issue). i don’t like the hype around it either. Nothing will beat good programming practices and discipline. TDD is a good practice. schleprock

Robert Vukovic wrote:

What about GUI programing ? What about multithreading? What about C++ ?

[schleprock]

leppie wrote:

It's only a benefit if you can test against something, eg some algorhithm.

absolutely not true. one small example, your end user uses the output from your application to automate something else, they expect your output to be in a specific order with a particular syntax. if you don't want to piss off your end user, you test that the output is correct anytime you change your application. testing is about ensuring that your code base at the time of compilation is acting in a fashion that your end user is expecting. while that does include testing of algorithmic correctness, it also includes correct output (which could be font, color, placement in the window, ...) for a given input. it should also include detecting and handling error conditions in a resonable way. simply exiting out unexpectedly on any error is NOT a resonable way of handling error conditions (and that is not necessarily algorithmic). schleprock

[schleprock]

Joe Woodbury wrote:

(One problem in TDD is finding that a fundamental code change will greatly improve the application but will render the tests invalid as written. This WILL happen often. The temptation is to compromise the code so the tests either don't have to be rewritten or the rewrite is minimal. If you aren't careful, you end up creating an application that passes all the tests, but doesn't solve the customer's problem. As a developer, we may proclaim this simply won't happen, but tell that to the people writing your paychecks.)

you're not writing good tests. the unit tests should be very specific tests that should never change unless you re-architect the product. regression tests should test the output in a way that allows for change in the output without invalidating the test. for example, if the output from your application is textual but you don't care about the order in which the output appears, sort the output from the application and then check for correctness. you've now gotten rid of the ordering issue. if you're testing a gui and you don't care about button position, write the test to bypass choosing the button via x/y location and call the method directly. have a single test that triggers a button push via position and you only need to update that one test when the button gets moved. tests need to be written to ignore things that you don't care about and only test what you do care about. schleprock

[BoneSoft]

I would tend to say that you don't see the benefit mostly because of the size of your team. When you have multiple people working on a code base, and a peppering of programmers of lesser skills, you needs something that can quickly throw red flags when a negative change ripples out. That said, it's just another tool which, when used correctly can be very beneficial. But unit tests are just like other code, crap in crap out. Great discussion. :)

---

Try code model generation tools at BoneSoft.com.

[JLengi]

If you can write 35K lines of bug-free code, then TDD is not for you. But, as for the rest of us, . . . The thing is, I bet you actually wrote a lot of tests. In fact, I bet you wrote some of the same tests many times. You just didn't save them. TDD gives you a framework to keep all those snippets of test code you inevitably write, even when not doing TDD. I also agree with other posts that say that the value of TDD increases with the size of the team.

[BoneSoft]

How was Dell? I noticed recently that they are hiring for a lot of development jobs.

---

Try code model generation tools at BoneSoft.com.

[Chris S Kaiser]

Well, as with any methodology you need to use it and see how and where it works for you and your situation. It doesn't matter which language you choose, as the unit test is just a contract that the app must fulfill. Some automated tests can work against guis, but what works for me is keeping it simple. Writing unit tests for components and libraries to ensure you get what you expect. I disagree with the other fellow that empirical tests aren't good. I think you need to balance both, part of that is going to be usability and no automated system will tell you that, you need humans. As to threading, well, a unit test in a client/server setup would have one test prewritten for the client and one for the server. Then multiply the clients to test for load, but there will always be the obscure bug that they won't find, although they might display the symptom such as deadlocks. So while yer mileage may vary, I would start simple, and see what works for you, and go with it. This statement is false.

[Kenneth Kasajian]

It doesn't sound to me that you're only anti-TDD. Sounds like you're saying you're anti-SQA in general. That's probably a separate discussion altogether. Honest, I had a hard time getting past the statement "I've never used it and I get by just fine." -- modified at 10:52 Wednesday 19th July, 2006

[feline_dracoform]

thank you for a thoughtful reply. i have saved it out and will read it / think about it, when i am no longer snowed under with work *rolls eyes*

zen is the art of being at one with the two'ness