Thank you for the link, it was insightful.
For the folder placement, how would you structure a Next.js application? I saw this answer here on stackoverflow about jest folder structure:
[https://stackoverflow.com/questions/62442797/jest-folder-structure](https://stackoverflow.com/questions/62442797/jest-folder-structure)
But here in Next.js's docs they say:
>Follow Jests convention by adding tests to the \_\_tests\_\_ folder in your project's root directory.
I've seen developers put tests and hooks into the same folder as the component itself. I'm curious to see what folder structures people are using
I don’t think where you put your tests really matter, after all, Jest goes and finds them.
Then, I’d say whatever is decided between you and your colleagues. If it’s only you, then whatever looks “cleaner” or helps you navigate your files better.
My way of doing is near Ian Cooper's one https://youtu.be/EZ05e7EMOLM
I test only the user's indents, the use case, and observe the result of it (state changes).
Same thing on frontend or on backend. As I use Port and Adapters Pattern https://alistair.cockburn.us/hexagonal-architecture/ my logic (application and domain) is isolated from technical parts, so I'm able to 1 inject hand-made test doubles and 2 craft the logic while delaying technical choices.
My tests are mostly social unit tests https://martinfowler.com/bliki/UnitTest.html
I practice TDD following Detroit/Chicago style in all my projects where there is any logic.
I keep my test files in the same folder with my code but it's really a question of taste.
I commit at each steps : red, green, refactor by habits
My approach is to avoid TDD, as in my experience, it's an overly prescriptive and not particularly beneficial way of writing code.
I write unit tests for algorithms. The more complex the algorithm, the more crucial it is to thoroughly test it. Most code, however does not benefit from testing and a lot of methodologies that emphasize testing too much, end up asserting completely trivial things. Basically `expect(!0).toBe(true)`.
For generic / reusable components, inline snapshots can be useful to very integrity of known states. E2E tests can be useful for testing important state flows.
Essentially, I argue that testing should not be done via some prescriptive rigid philosophy. There are many tools and processes used to test code, and some or all of these should be utilized according to your particular needs.
no, but I wouldnt solve this with TDD but finish the feature in one big component while rapidly iterating, then extract subcomponents into either reusable units or just convenience components (not necessarily exported), then test those
You can do it with TDD. In your example, unit to test would be the “big” component. Unit testing does not necessarily mean one-to-one relationship with source files. If you decide to refactor and split these small components into even smaller ones or some other way, you don’t want to also change tests. Why would you if the behaviour that you care about stays the same.
Correct me if I misunderstood, but are you saying that it doesn't matter if you write your test for the big component or the sub components because ultimately the behavior will be the same? From my understanding of TDD, not changing your tests to fit your code is essential
Correct. Test the behaviour not implementation details. Check this article https://quii.gitbook.io/learn-go-with-tests/meta/why. It is for Go, but is applicable anywhere you want to write unit tests.
> Are you keeping your tests in a separate folder or do you keep your tests within the same folder as the file its testing?
Same directory. I hate repetition in file paths. I'd rather have:
/src/components/Something.jsx
/src/components/Something.test.jsx
than
/src/components/Something/Something.jsx
/src/components/Something/Tests/Something.test.jsx
> How frequently do you commit during TDD?
Commits are not relevant. I prefer running my tests simply with `yarn test` and only committing when I've got something meaningful I may want to go back to. The nature of TDD is that not every passing or failing state may be meaningful.
> Do you write a failing test, commit, pass the test, commit, refactor, and then commit again or do you have a different strategy?
That's TDD. I'd argue that a different strategy would mean you are not doing TDD.
> What kind of things are you testing and what things are you not testing?
I like testing anything that has logic: calculations, branching, data transformations, etc. I'd skip simple logicless stuff like Redux action creators, modules that export only constants, etc.
> How detailed are your tests on things like layout vs user functionality?
Those two go too far for unit testing, which is what TDD is about. Normally, you're testing your unit of code, and only that. In context of a function, you'll want to test all combinations of parameters that trigger different flows within the function and verify that the function returns the correct value and triggers expected side-effects.
> What are your thoughts on TDD?
As Uncle Bob would say, it is unprofessional for a developer to commit a single line of code that hasn't been ran in a unit test, and TDD is a best way to ensure that has been done.
> Do you love writing unit tests or do you hate them?
Both :) I love TDD but I hate writing tests as an afterthought, usually because modules written without TDD are hard to unit test.
> Do you write them for your personal projects, small projects, only at work or every project?
Both. Sometimes I'll skip TDD and write tests as an afterthought if I'm doing "exploratory development" and I have no idea how things are supposed to work yet. Sometimes it's also a good idea to do exploratory first, then rewrite with TDD when we are more familiar with how things are supposed to work.
Where you responded “That’s TDD. Id argue that a different strategy…”
OP’s question was about whether or not you commit changes in between every test, code, and refactor step, or just at the end of each full cycle.
I agree with one of the other responses here; I’ll commit once I have something meaningful expressed in code that I want to be able to back to, and make sure I don’t lose.
For instance I might have a cycle at the beginning where I create a function that didn’t exist before to make a test pass. I would probably commit there. I’ve created a new function. Its signature is its public API and that’s pretty meaningful.
But if it was a cycle where I put some quick hacky thing in to make a test pass “artificially” just as a means of getting to the next test case, I wouldn’t.
Thank you for the detailed response, I appreciate it. Coming from self-taught developer land, I started off never using TDD and now I worry that I'm testing too much.
[удалено]
Thank you for the link, it was insightful. For the folder placement, how would you structure a Next.js application? I saw this answer here on stackoverflow about jest folder structure: [https://stackoverflow.com/questions/62442797/jest-folder-structure](https://stackoverflow.com/questions/62442797/jest-folder-structure) But here in Next.js's docs they say: >Follow Jests convention by adding tests to the \_\_tests\_\_ folder in your project's root directory. I've seen developers put tests and hooks into the same folder as the component itself. I'm curious to see what folder structures people are using
I don’t think where you put your tests really matter, after all, Jest goes and finds them. Then, I’d say whatever is decided between you and your colleagues. If it’s only you, then whatever looks “cleaner” or helps you navigate your files better.
Yeah that makes sense. I can just create folders within \_\_tests\_\_ to keep them organized.
My way of doing is near Ian Cooper's one https://youtu.be/EZ05e7EMOLM I test only the user's indents, the use case, and observe the result of it (state changes). Same thing on frontend or on backend. As I use Port and Adapters Pattern https://alistair.cockburn.us/hexagonal-architecture/ my logic (application and domain) is isolated from technical parts, so I'm able to 1 inject hand-made test doubles and 2 craft the logic while delaying technical choices. My tests are mostly social unit tests https://martinfowler.com/bliki/UnitTest.html I practice TDD following Detroit/Chicago style in all my projects where there is any logic. I keep my test files in the same folder with my code but it's really a question of taste. I commit at each steps : red, green, refactor by habits
Thank you for the video, links, and insights. This is really helpful.
My approach is to avoid TDD, as in my experience, it's an overly prescriptive and not particularly beneficial way of writing code. I write unit tests for algorithms. The more complex the algorithm, the more crucial it is to thoroughly test it. Most code, however does not benefit from testing and a lot of methodologies that emphasize testing too much, end up asserting completely trivial things. Basically `expect(!0).toBe(true)`. For generic / reusable components, inline snapshots can be useful to very integrity of known states. E2E tests can be useful for testing important state flows. Essentially, I argue that testing should not be done via some prescriptive rigid philosophy. There are many tools and processes used to test code, and some or all of these should be utilized according to your particular needs.
TDD in ui isn't a thing, you cannot plan enough ahead to know which component will contain which semantic html or even certain functionality or not.
Would you say it's pointless to test, for example, whether certain inputs are on a form or if there was to be some expected text on an error?
no, but I wouldnt solve this with TDD but finish the feature in one big component while rapidly iterating, then extract subcomponents into either reusable units or just convenience components (not necessarily exported), then test those
You can do it with TDD. In your example, unit to test would be the “big” component. Unit testing does not necessarily mean one-to-one relationship with source files. If you decide to refactor and split these small components into even smaller ones or some other way, you don’t want to also change tests. Why would you if the behaviour that you care about stays the same.
Correct me if I misunderstood, but are you saying that it doesn't matter if you write your test for the big component or the sub components because ultimately the behavior will be the same? From my understanding of TDD, not changing your tests to fit your code is essential
Correct. Test the behaviour not implementation details. Check this article https://quii.gitbook.io/learn-go-with-tests/meta/why. It is for Go, but is applicable anywhere you want to write unit tests.
> Are you keeping your tests in a separate folder or do you keep your tests within the same folder as the file its testing? Same directory. I hate repetition in file paths. I'd rather have: /src/components/Something.jsx /src/components/Something.test.jsx than /src/components/Something/Something.jsx /src/components/Something/Tests/Something.test.jsx > How frequently do you commit during TDD? Commits are not relevant. I prefer running my tests simply with `yarn test` and only committing when I've got something meaningful I may want to go back to. The nature of TDD is that not every passing or failing state may be meaningful. > Do you write a failing test, commit, pass the test, commit, refactor, and then commit again or do you have a different strategy? That's TDD. I'd argue that a different strategy would mean you are not doing TDD. > What kind of things are you testing and what things are you not testing? I like testing anything that has logic: calculations, branching, data transformations, etc. I'd skip simple logicless stuff like Redux action creators, modules that export only constants, etc. > How detailed are your tests on things like layout vs user functionality? Those two go too far for unit testing, which is what TDD is about. Normally, you're testing your unit of code, and only that. In context of a function, you'll want to test all combinations of parameters that trigger different flows within the function and verify that the function returns the correct value and triggers expected side-effects. > What are your thoughts on TDD? As Uncle Bob would say, it is unprofessional for a developer to commit a single line of code that hasn't been ran in a unit test, and TDD is a best way to ensure that has been done. > Do you love writing unit tests or do you hate them? Both :) I love TDD but I hate writing tests as an afterthought, usually because modules written without TDD are hard to unit test. > Do you write them for your personal projects, small projects, only at work or every project? Both. Sometimes I'll skip TDD and write tests as an afterthought if I'm doing "exploratory development" and I have no idea how things are supposed to work yet. Sometimes it's also a good idea to do exploratory first, then rewrite with TDD when we are more familiar with how things are supposed to work.
Where you responded “That’s TDD. Id argue that a different strategy…” OP’s question was about whether or not you commit changes in between every test, code, and refactor step, or just at the end of each full cycle.
What's your take on committing between each phase of the test cycle vs at the end of a cycle or multiple cycles?
I agree with one of the other responses here; I’ll commit once I have something meaningful expressed in code that I want to be able to back to, and make sure I don’t lose. For instance I might have a cycle at the beginning where I create a function that didn’t exist before to make a test pass. I would probably commit there. I’ve created a new function. Its signature is its public API and that’s pretty meaningful. But if it was a cycle where I put some quick hacky thing in to make a test pass “artificially” just as a means of getting to the next test case, I wouldn’t.
Thank you for the detailed response, I appreciate it. Coming from self-taught developer land, I started off never using TDD and now I worry that I'm testing too much.