Hacker News Reader

> 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.

> 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?

"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.

> 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.

" 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.

> 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.

Agree. The key to good tests seems to make them neither unit tests or e2e tests, but something in between. API tests if you have an API, or "medium sized module" tests in other systems.

Unit tests and e2e tests have value too, but they're a lot more work to maintain for less value IMO.

> But don't start WITH them. You'll build rigid systems.

It depends. If you'll test implementation - sure. But if you test use cases - not necessarily,

> 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.

>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.

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.

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-...

[1]: https://nickjanetakis.com/blog/design-your-web-uis-faster-by...

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

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.

> 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.

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

>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.

> 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

> 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".

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?"

Exactly. They can be a great form of "case analysis", and can also be translated back into business-analyst-speak or use cases.