4 ms·

Let's say I am writing the front end of a web app. I have no idea what its going to look like. What I do is just get something on the screen, figure out what'

• lmm 14y ago
  You figure out what it should look like (which shouldn't involve writing any code - use html or a dedicated UI mockup tool), then write tests for that, then write code for it. If you start by writing code you'll end up with the UI that was easiest to code rather than the UI that looks how the end user will want it to.
  • mgkimsal 14y ago
    Semantically (and probably officially) that's not really 'test first'. You wrote something else (html) then wrote a test for that. You should be writing a test that checks for the existence of that specific html, then watching it fail, then writing the HTML. If you think that's wrong, then 'test first' isn't always the 'right way'. No, I'm not being facetious or sarcastic. Just pointing out that 'test first' isn't a requirement. It's an approach that has some good points. I 've done portions of some projects 'test first' and they generally turn, but it's not an approach I use exclusively 100% of the time. "If you start by writing code you'll end up with the UI that was easiest to code rather than the UI that looks how the end user will want it to." The problems with this thinking (which I mostly agree with, btw) is that not every project gets to involve checking with end users, nor do end users really understand what/how something should work until they're using something that actually allows a degree of interactivity. They may not even be aware of what's possible until they're poking around 'live'. While you might be reluctant to rejigger large portions of what you've done to move toward "easiest to code vs what they want/need", that's a different problem. It's a problem you need to be aware of, and ready to tackle when you cross it (and you'll know when because you're now aware of it).
    • lmm 14y ago
      The HTML you wrote isn't part of the live code, it's part of the test. It's perfectly normal to write some sort of skeleton/dummy as part of writing your tests - it's impossible to write a test without an interface to call into, after all.
      • mgkimsal 14y ago
        " it's impossible to write a test without an interface to call into, after all" This is not at all what pure 'test first' has even been described as to me. You'd write a test - run it to watch it fail - then write the code to make the test pass. Whether that code is interface/ui/logic/whatever shouldn't make any difference. http://en.wikipedia.org/wiki/Test-driven_development#Test-driven_development_cycle http://en.wikipedia.org/wiki/Test-driven_development#Test-dr... "In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented." EDIT: "Test-driven development is difficult to use in situations where full functional tests are required to determine success or failure. Examples of these are user interfaces... " The TDD article on wikipedia is seeming to confirm that TDD for UI is hard (or is at least a shortcoming of a TDD approach).
• scott_w 14y ago
  I like to apply a few different methods to developing web applications: I write unit tests to ensure the correct data comes out. This usually involves doing a quick "get a blank page loading" bit of boilerplate, then putting the tests (and required data) in place. This involves a fair bit of discussion, sitting down with a calculator, and drawing on the whiteboard. Then I write the code to pass the tests. In parallel, the screens are being designed and put up on our wiki. Once this is done, I'll make the screen look like the mock-up, which involves a visual "test". For more complex stuff, this is done in a more piecemeal fashion, although the design is usually put in place in one go. What I'm working on right now has involved 4 iterations of this so far. For what it's worth, writing the tests first forces you to make your code easier to test which, for a web app, is incredibly useful. I've seen some web applications developed without testing in mind, which tend to have the effect of "funnelling" the user through specific steps. They tend to get a little fragile when the user inevitably steps outside the narrow corridor they're pushed down.