16

My manager's manager (... and his manager, and everyone else who wears a suit) at my firm is talking about how we really need to transition to TDD because it's better than what we're doing now. Unfortunately we're dealing with a very old system that has zero automated testing. A lot of this stems from the lack of time allocated to set up any kind of framework around it, and the fear that such a framework would take a lot of time to maintain and its only output would increase developer workload. (You and I both see that as a good thing. You may remember a couple of my other questions surrounding it.)

We recently hired a 'release manager' who basically just sets up a project management system and looks at all the projects coming in and makes sure they have all their documentation. Apparently it's required for SOX compliance to have one, even if it doesn't really seem that his title and his job description match up. One of the things he now looks for (and rejects the proposal if it is missing) is a testing document: a series of steps that the analyst has put forth about how to test the new feature or bug fix they're championing. I won't go into the quality of the document, but at least most of them are more than "deploy to test environment, analyst to test". Let's just assume that enough of them are good enough quality to give someone at least the happy path testing.

Is this considered TDD? I suppose I always thought TDD meant you had to have, say, a unit test written before your class, or an integration test written before you wrote your bridging code between two modules.

Now, I don't want to fall into the "we're Agile!" trap. I think it's silly to sit in a meeting and argue about whether we're actually doing TDD or not. But what I think is important is to be able to line up what we're doing with the lessons others have learned. If we are doing (what the general community calls) TDD then it stands to reason that we are likely to benefit from advice geared at teams that do TDD.

So my questions are:

  • Are the tests mandated by TDD required to be automated?
  • Are we doing what the general community calls TDD?
  • If we aren't what would we need to change to do so?
  • Regardless of if we "are" or not, is there some red flag indicated here that would let us be more in line with the TDD community?

Edit:

So far, it would appear that yes, you do need automated tests in order to be "TDD". So perhaps a follow-up question would be how much of TDD would translate to an "only manual testing" environment?

Improve this question
3
  • 2
    You wrote a good question, glowcoder. If you were to ask your management chain what specifically they want to get out of TDD that they don't get today, what do you think they would say? Do you think they literally want exactly TDD -- nothing more and nothing less? Or do you think they are more interested in a set of things that they believe to be true about TDD?
    – user246
    Oct 17, 2011 at 1:55
  • Well, I think (as you may infer from my other posts) is that they aren't sure what they want. They make billions in manufacturing, and every internal process they've ever had ran great under their manufacturing model. But it doesn't scale to technology and it's finally catching up to them. But reversing 20 years of a thought process is hard. So they go to conferences and pick up ideas and aren't entirely sure how to fit all the pieces together. So I would say that what they want is just better quality software. I'm not sure they could give specifics beyond that.
    – corsiKa ♦
    Oct 17, 2011 at 4:11
  • I know what I don't want is some certificate that says "We're doing TDD! Yay!" Rather, I'd like to apply whatever good principles I can wherever I can. And while I'd like to convince them to do automated testing, I'm willing to settle for better manual testing. I mean, the test documents from the analysts is something new. My primary goal is to find some ideas I can bring to the table given the environment I'm in.
    – corsiKa ♦
    Oct 17, 2011 at 4:15

5 Answers 5

Reset to default
7

TDD is generally code designed by developers first writing unit tests. There is a fundamental difference in how developers and QA people approach the concept of test. It is more helpful to think of unit tests as code contracts. These will be updated and changed over time and that is the primary difference. To a QA person a test, once working, should always work unless the feature has been explicitly removed. To a developer unit tests are updated/modified whenever the code they cover is modified. This does not mean unit tests serve no purpose. They are great for testing business rules and great for informing developers of what a given method does or should do. Unit tests typically break down in finding bugs that involve interaction between different areas. Testing documents typically are outlines of a test approach and areas to be covered. Then a test plan with test steps is created. Unit tests should be run with every build for them to serve any real purpose. Test Plans should be reviewed for automation after successful runs. Often what you assume needs to be tested initially is not what turns out to be needed over time. I think the trick is to make a good test plan for a given feature then pair done the test cases after the feature is complete adding the "core" test cases of the feature to regression.

Improve this answer
2
  • That's interesting, but we don't actually do builds in our development environment. We... we send the code out to the various systems and compile on the production box. That's another aspect of the process I'm trying to get changed :-)
    – corsiKa ♦
    Oct 20, 2011 at 13:28
  • If the code is never built before it hits a production box how do you know it will even compile let alone work in some way?
    – Ardesco
    Aug 22, 2013 at 13:19
7

TDD is, in its truest sense, exactly as Aruna described it. The developer writes automated unit tests, watches the test fail, then proceeds to write the code that the unit test was meant to test, codes until it passes, and then refactors, all the while maintaining the core unit tests.

Ideally (in my world at least), all of the tests should also be organized into suites in a test runner, such as JUnit (no experience with Java, but, I seem to remember you stating that you used Java at your company). That way, you can always also look to see if your changes happened to create a bug in any previous code that you've tested, before you hand it off to be tested.

No real red flags that I can see (also fighting a flu and fever so I may be wrong), but, if you were to take a look at JUnit, or any other xUnit, do you think that you could write quick tests to test each of your methods? Do you really think it would take a whole lot longer? For unit tests, and TDD in general, there typically doesn't need to be a whole lot of framework there. If it will only take you a an extra half-hour to an hour a day to write the tests, and your own output ends up being more reliable and up to the customer's spec's, will your manager mind?

EDIT based on your edit: In my own mind, although maybe not necessarily in the minds of others, TDD is automated. Manually testing your code after being written is just a good practice. If you do want to take the motions of TDD however, and apply them in a manual, you will probably see some improvement in immediate code.

  1. Write down exactly what you want the code to do
  2. Write the code
  3. Assert that the code functions exactly as expected.

A positive to this is that you are able to give these tests to the change champions.

A downside, if you want to ensure that it is still working as expected in the future, you must do it manually.

Improve this answer
2
  • Actually, the project that needs the most love is in Progress ABL. The Java questions I have are mostly for my side projects :-) I know for a fact that automated testing won't fly with management because it's too big of an investment. But they're also saying they want TDD. But this has given me some insights for which I will update my question.
    – corsiKa ♦
    Oct 17, 2011 at 1:26
  • Re: your edit. Your positive is actually what's causing it all :-) The champions are now being forced to create a document for the developers. So they write this document that says what the new feature or function is supposed to do, and we can follow that document. It also helps to stop them from changing their mind :-) And the downside is very big, because if they want work on the same function again, but just a different aspect of it, they're unlikely to go through the first test, only focusing on the second.
    – corsiKa ♦
    Oct 18, 2011 at 16:24
4

I had been into Test Driven Development and this is the way we approached it. The Developer develops automated unit tests even before he starts coding. Suppose there are 18 tests to validate the payment method. Before he writes the code, all the 18 tests would fail. After the coding is completed he would ensure that all the 18 automated unit tests are passing. After unit testing is done he would handover testing to the QA.

We had automated unit tests in our company. I am not sure if it is mandatory to have it automated.

Improve this answer
5
  • I really can't imagine non-automated unit tests, or how non-automated unit tests would be beneficial at all.
    – joshin4colours
    Oct 17, 2011 at 3:21
  • Most developers do not have the time or interest to do test automation and they settle with manual unit testing. Did you mean to say that manual unit testing w.r.t TDD isn't beneficial? If yes, I can totally relate to what you said. It doesn't make sense for the developers to manually unit test before coding starts and then again repeatedly do the same manual unit testing till all the tests pass after the coding is complete. It's inefficient and cannot yield much benefits.
    – Aruna
    Oct 17, 2011 at 5:47
  • 1
    That is more or less what I meant. The whole idea of unit tests is that they provide fast checks on code at the unit level. Automating them makes them more efficient and standardized. Doing manual unit testing would likely be quite inefficient, not to mention unstandardized (especially if devs are under time pressure).
    – joshin4colours
    Oct 17, 2011 at 17:54
  • To say "most developers do not have the time or interest to do test automation" is a bit narrow and most dev's I know now definately have a different point of view compared to say 5 years ago. A dev who doesn't unit test his/her code is incompetent at best. Also, what the heck is a manual unit test? "Manual unit testing" is an oxymoron.
    – Bj Rollison
    Oct 20, 2011 at 15:47
  • Good to know that the dev is changing their views on test automation nowadays. I have seen DEV becoming demotivated when they are asked to do test automation. It should change and I am glad its not happening everywhere.
    – Aruna
    Oct 20, 2011 at 20:22
3

None of TDD is manual testing. The whole idea of the "Driven"-part is that you get a collection of tests that run every time you change something to your source code, in order to maintain stability and prevent regression issues.

Tests don't, howevery, need to be unit tests. If you prefer, they could be automated UI tests for example.

Improve this answer
2

This is a really interesting question, but it seems like the place to start is not at "what is TDD?" but more like "how can we not do things that have an overwhelming probability of shooting ourselves in the foot?"

You might look through a post by "Joel on Software". It's something of a canonical reference for best practices around software development in general. It was written back in Bubble 1.0, but the concepts are still relevant today.

Improve this answer
1
  • 1
    Being quite familiar with the Joel test, I have scored my firm as a 3.5. (In order, yes no no yes no no no no yes no (yes, but not dedicated) no.) However, it really is just a mechanism by which you can compare various teams. Also, we're not a software firm - we're a manufacturing firm, putting us at the whim of those who are not so "best-practicey" savvy. As such, I am trying to find small process changes that either feed into government requirements, or are entirely contained within development, as a way to circumvent corporate inertia (which is a serious factor).
    – corsiKa ♦
    Oct 20, 2011 at 23:25

Not the answer you're looking for? Browse other questions tagged or ask your own question.