11 ms·

> Spec first, then code and then later > Be ready to throw your code away Then why would it be useful to have the spec first if you're expecting to throw it

> Spec first, then code and then later > Be ready to throw your code away Then why would it be useful to have the spec first if you're expecting to throw it away anyway? Better combine this advice, > Write steps as comments with a higher level language, and write code instead of comments, and have fun developing what you think is the product you need. You'll see plenty of corner cases, learn tons of new stuff about your domain that you didn't even think existed and then you'll want to start over since many of your initial assumptions will be wrong anyway by that time or you'll see new extra features that you couldn't have possibly discovered without actually having a toy product to play with and try new ideas with. Tests? No, definitely not on the first run. Maybe only for documentation purposes in legacy systems. But don't take away all the fun by starting with tests. You'll paint yourself into a corner. This seems like 30 years of experience in a corporate environment. I would take these recommendations with a grain of salt. I would venture to say that whoever starts with "I have x years of experience" or "I'm an Y language developer" is mostly bulshitting you or doesn't really know what he's talking about, so he'll need to have a badge to shove it up your face to demonstrate his qualities.

MrGilbert 7y ago
> This seems like 30 years of experience in a corporate environment. Well... That's where the money's at, right? > Tests? No, definitely not on the first run. Maybe only for documentation purposes in legacy systems. But don't take away all the fun by starting with tests. Kindly disagree. In a corporate environment (at least the one's I've worked so far), you HAVE to start with the tests. From my experience, people maintaining your code after you've left the company (or you are sick, whatever) will be grateful to have a testsuite that can verify the edge cases are still working after their changes have been deployed. Also, when the first working lines have been written, there was no way we would revisit them to write test on top. I need tests to verify that what I've just written actually works. Others might create a "ExampleConsoleApp1" for this, but then I can also write a test.
- molteanu 7y ago
  > Maybe only for documentation purposes in legacy systems. > people maintaining your code after you've left the company That's what a legacy system is. I agree. That's a good use of tests. But don't start WITH them. You'll build rigid systems. > Well... That's where the money's at, right? Agree with this also. But this is (or should be) hacker news, so we look for better ways to make software, regardless if it makes money or not. Or maybe we should rename it Financial Times?
  - UK-Al05 7y ago
    "But don't start WITH them. You'll build rigid systems" - Only if you design them badly. Most people write terrible tests, which are over mocked. You should test input(say simulate http post call) then check the thing is in the fake database or even better a call to retrieve the item. You can completely change the way its implemented in between.
    - u801e 7y ago
      > Most people write terrible tests, which are over mocked. You should test input(say simulate http post call) then check the thing is in the fake database You're still using mocks in that case. You can avoid using mocks entirely by decoupling your tests from external dependencies. That is, instead of making a HTTP post request to the application, test a method that takes the content of the HTTP request as a parameter and assert on the return value. For the database, you can test a method that takes parameters and returns the appropriate query. Then integration tests can be used to test the interactions between different parts of the system.
      - UK-Al05 7y ago
        " That is, instead of making a HTTP post request to the application, test a method that takes the content of the HTTP request as a parameter and assert on the return value" The http post is the input into OUR system under test, not an external dependency. Nothing is mocked. I find going through the entire http pipeline catches misconfiguration issues. "For the database, you can test a method that takes parameters and returns the appropriate query." - That's what the fake database does. Implements the interface to the database. In this case implements a fake query method. Nothing is mocked. Stubed but not mocked.
reallydontask 7y ago
> Then why would it be useful to have the spec first if you're expecting to throw it away anyway? The idea is that you should be ready to throw your code away if the requirements change. If the spec changes (e.g. your own made up spec to the client's actual spec) then be ready to throw away some (all?) code.
- js8 7y ago
  GP's question reminds me of the quote: Plans are worthless, but planning is essential.
de_watcher 7y ago
> Tests? No, definitely not on the first run. Maybe only for documentation purposes in legacy systems. But don't take away all the fun by starting with tests. You'll paint yourself into a corner. Trying to squeeze in the tests into existing system is painful. So better do the tests before it had become a "legacy system to document". Tests should be written before and during writing the new system. That's because they are the executable language for the results you want to get from the system. The two other options are: use plain text to document your manual actions and expected results, don't document your manual actions and expected results.
- protonimitate 7y ago
  >Trying to squeeze in the tests into existing system is painful. So better do the tests before it had become a "legacy system to document". This, but also if you code first then write tests you try to write tests based on your interpretation of how the code you already wrote currently works, when its better to write tests to outline and define how the code _should_ work in the future. >You'll paint yourself into a corner. I find it is the exact opposite. If you write all your code first, then write tests, you will inevitably find a bug and refactoring working code to fit a test is infinitely harder than adding more tests or replacing irrelevant ones.
- marcosdumay 7y ago
  Trying to test ill-defined software is a recipe for failure. At the same time, trying to create well defined software without tests also leads to certain doom. Know where you are.
gitgud 7y ago
>I would venture to say that whoever starts with "I have x years of experience" or "I'm an Y language developer" is mostly bulshitting you or doesn't really know what he's talking about, so he'll need to have a badge to shove it up your face to demonstrate his qualities. A better approach is to demonstrate your skills and why it's important, then let people ask and wonder about your background... Basically, shoving experience or qualifications in my face doesn't make me respect your point of view more, it just makes me think you can't be humble and want to make yourself look good. This is actually great advice for both people with experience and people listening to them.
pjc50 7y ago
> don't take away all the fun by starting with tests Depends what you're doing. For interactive programs, automated testing is more painful than just firing it up and testing manually, at least at the beginning. For noninteractive systems it may be much easier to start with a test as a spec: "parse this file and produce this output".
- Nasrudith 7y ago
  Reminds me of one unusual application of tests - working with inadequate or overadequate documentation (filled with many lines but difficult to find what you need) they work well as "scratch pads" for details which are unclear like "Does it return null or throw an exception when you attempt to remove something not in the collection?"
  - pjc50 7y ago
    Exactly. They can be a great form of "case analysis", and can also be translated back into business-analyst-speak or use cases.
nickjj 7y ago
I have ~20 years of experience as a freelancer and I don't like TDD, but I do think writing tests early is important because they give you the confidence to refactor your "fun / getting it to work" code. My workflow is basically: - Plan the project out, but not super detailed, this is more like a high level overview of features. I did a 90 minute video live on this process once[0]. - Think about each state of what a feature could be in. Here's another video[1] showing that process. - Design some pages around your states (if you planned a user registration system, start designing the register form) - Dive into the code and implement one of the features (using pseudo code to help with the flow initially if needed) - Write some tests to demonstrate that what you have works as you intended - Heavily refactor your code if needed, leaning on your tests and refining them as you come across edge cases, etc. Honestly the above never fails for both small and large projects. You always have something small and focused to work on and the code you produce typically ends up being in good shape by the time you reach the end of the workflow. It's a fast cycle too (easily multiple loops per day) once you have the states ironed out. [0]: https://nickjanetakis.com/blog/live-demo-of-planning-a-real-world-web-application-from-scratch https://nickjanetakis.com/blog/live-demo-of-planning-a-real-... [1]: https://nickjanetakis.com/blog/design-your-web-uis-faster-by-planning-out-each-different-state https://nickjanetakis.com/blog/design-your-web-uis-faster-by...
- hyperbole 7y ago
  Code is legacy the moment it's checked in - not writing tests is the equivalent of expecting the game of telephone to go flawlessly always and forever for every corner and major case written... This type of optimism when looked up in the OED has one definition: nope
  - Sahhaese 7y ago
    That is why I like Michael Feathers' definition of legacy code, which is (paraphrasing): > Legacy code is code not under test That said, I'm not against the existence of legacy code, but any bugs damn well should be written up as tests to catch regressions. That way new development can be done without tests (full TDD is tedious and often way too coupled to implementation imo) but any bugs are captured in a way that can't be tests written against the implementation and guard against regression.
deleted 7y ago
[deleted]
karlp 7y ago
> Write steps as comments with a higher level language, and write code instead of comments, and have fun developing what you think is the product you need. Hard disagree on that, there is nothing more annoying than reading code without plain comments, it's always less obvious than the original developer thought and the worst is that it always happen to your own code

MrGilbert 7y ago

> This seems like 30 years of experience in a corporate environment. Well... That's where the money's at, right? > Tests? No, definitely not on the first run. Maybe only for documentation purposes in legacy systems. But don't take away all the fun by starting with tests. Kindly disagree. In a corporate environment (at least the one's I've worked so far), you HAVE to start with the tests. From my experience, people maintaining your code after you've left the company (or you are sick, whatever) will be grateful to have a testsuite that can verify the edge cases are still working after their changes have been deployed. Also, when the first working lines have been written, there was no way we would revisit them to write test on top. I need tests to verify that what I've just written actually works. Others might create a "ExampleConsoleApp1" for this, but then I can also write a test.

molteanu 7y ago
> Maybe only for documentation purposes in legacy systems. > people maintaining your code after you've left the company That's what a legacy system is. I agree. That's a good use of tests. But don't start WITH them. You'll build rigid systems. > Well... That's where the money's at, right? Agree with this also. But this is (or should be) hacker news, so we look for better ways to make software, regardless if it makes money or not. Or maybe we should rename it Financial Times?
- UK-Al05 7y ago
  "But don't start WITH them. You'll build rigid systems" - Only if you design them badly. Most people write terrible tests, which are over mocked. You should test input(say simulate http post call) then check the thing is in the fake database or even better a call to retrieve the item. You can completely change the way its implemented in between.
  - u801e 7y ago
    > Most people write terrible tests, which are over mocked. You should test input(say simulate http post call) then check the thing is in the fake database You're still using mocks in that case. You can avoid using mocks entirely by decoupling your tests from external dependencies. That is, instead of making a HTTP post request to the application, test a method that takes the content of the HTTP request as a parameter and assert on the return value. For the database, you can test a method that takes parameters and returns the appropriate query. Then integration tests can be used to test the interactions between different parts of the system.
    - UK-Al05 7y ago
      " That is, instead of making a HTTP post request to the application, test a method that takes the content of the HTTP request as a parameter and assert on the return value" The http post is the input into OUR system under test, not an external dependency. Nothing is mocked. I find going through the entire http pipeline catches misconfiguration issues. "For the database, you can test a method that takes parameters and returns the appropriate query." - That's what the fake database does. Implements the interface to the database. In this case implements a fake query method. Nothing is mocked. Stubed but not mocked.

reallydontask 7y ago

> Then why would it be useful to have the spec first if you're expecting to throw it away anyway? The idea is that you should be ready to throw your code away if the requirements change. If the spec changes (e.g. your own made up spec to the client's actual spec) then be ready to throw away some (all?) code.

js8 7y ago
GP's question reminds me of the quote: Plans are worthless, but planning is essential.

de_watcher 7y ago

> Tests? No, definitely not on the first run. Maybe only for documentation purposes in legacy systems. But don't take away all the fun by starting with tests. You'll paint yourself into a corner. Trying to squeeze in the tests into existing system is painful. So better do the tests before it had become a "legacy system to document". Tests should be written before and during writing the new system. That's because they are the executable language for the results you want to get from the system. The two other options are: use plain text to document your manual actions and expected results, don't document your manual actions and expected results.

protonimitate 7y ago
>Trying to squeeze in the tests into existing system is painful. So better do the tests before it had become a "legacy system to document". This, but also if you code first then write tests you try to write tests based on your interpretation of how the code you already wrote currently works, when its better to write tests to outline and define how the code _should_ work in the future. >You'll paint yourself into a corner. I find it is the exact opposite. If you write all your code first, then write tests, you will inevitably find a bug and refactoring working code to fit a test is infinitely harder than adding more tests or replacing irrelevant ones.
marcosdumay 7y ago
Trying to test ill-defined software is a recipe for failure. At the same time, trying to create well defined software without tests also leads to certain doom. Know where you are.

gitgud 7y ago

>I would venture to say that whoever starts with "I have x years of experience" or "I'm an Y language developer" is mostly bulshitting you or doesn't really know what he's talking about, so he'll need to have a badge to shove it up your face to demonstrate his qualities. A better approach is to demonstrate your skills and why it's important, then let people ask and wonder about your background... Basically, shoving experience or qualifications in my face doesn't make me respect your point of view more, it just makes me think you can't be humble and want to make yourself look good. This is actually great advice for both people with experience and people listening to them.

pjc50 7y ago

> don't take away all the fun by starting with tests Depends what you're doing. For interactive programs, automated testing is more painful than just firing it up and testing manually, at least at the beginning. For noninteractive systems it may be much easier to start with a test as a spec: "parse this file and produce this output".

Nasrudith 7y ago
Reminds me of one unusual application of tests - working with inadequate or overadequate documentation (filled with many lines but difficult to find what you need) they work well as "scratch pads" for details which are unclear like "Does it return null or throw an exception when you attempt to remove something not in the collection?"
- pjc50 7y ago
  Exactly. They can be a great form of "case analysis", and can also be translated back into business-analyst-speak or use cases.

nickjj 7y ago

I have ~20 years of experience as a freelancer and I don't like TDD, but I do think writing tests early is important because they give you the confidence to refactor your "fun / getting it to work" code. My workflow is basically: - Plan the project out, but not super detailed, this is more like a high level overview of features. I did a 90 minute video live on this process once[0]. - Think about each state of what a feature could be in. Here's another video[1] showing that process. - Design some pages around your states (if you planned a user registration system, start designing the register form) - Dive into the code and implement one of the features (using pseudo code to help with the flow initially if needed) - Write some tests to demonstrate that what you have works as you intended - Heavily refactor your code if needed, leaning on your tests and refining them as you come across edge cases, etc. Honestly the above never fails for both small and large projects. You always have something small and focused to work on and the code you produce typically ends up being in good shape by the time you reach the end of the workflow. It's a fast cycle too (easily multiple loops per day) once you have the states ironed out. [0]: https://nickjanetakis.com/blog/live-demo-of-planning-a-real-world-web-application-from-scratch https://nickjanetakis.com/blog/live-demo-of-planning-a-real-... [1]: https://nickjanetakis.com/blog/design-your-web-uis-faster-by-planning-out-each-different-state https://nickjanetakis.com/blog/design-your-web-uis-faster-by...

hyperbole 7y ago
Code is legacy the moment it's checked in - not writing tests is the equivalent of expecting the game of telephone to go flawlessly always and forever for every corner and major case written... This type of optimism when looked up in the OED has one definition: nope
- Sahhaese 7y ago
  That is why I like Michael Feathers' definition of legacy code, which is (paraphrasing): > Legacy code is code not under test That said, I'm not against the existence of legacy code, but any bugs damn well should be written up as tests to catch regressions. That way new development can be done without tests (full TDD is tedious and often way too coupled to implementation imo) but any bugs are captured in a way that can't be tests written against the implementation and guard against regression.

deleted 7y ago

[deleted]

karlp 7y ago

> Write steps as comments with a higher level language, and write code instead of comments, and have fun developing what you think is the product you need. Hard disagree on that, there is nothing more annoying than reading code without plain comments, it's always less obvious than the original developer thought and the worst is that it always happen to your own code