Half the time the problem is easy to understand and you can generally find a solution through google. But other times your presented with a problem that you just don't know where to start, what do you do in this situation?

I learnt from this book that you brute force the problem, basically you try every approach that's possible, this is hard because the question is so confusing that you don't take a logical approach as it's unclear of what your options are.

Half the problem with code is understanding someone elses code, what does each thing do? Half of these divs don't really explain what it does.

I'm used to using google, but not used to taking a logical approach of bruteforcing, is there anything I can use that can aid with this? Half the time I just can't be bothered to write each attempt down on a notepad, half the time it's hard to see every option you could take to solving a problem, half the time you don't even know what their code does.

At college the students could solve any problem and I'm left confused of where to even start. The standard approach people take is make an attempt and update the site, the problem here is you get confused to what you've already tried + you don't really understand enough to know what to do next.

Edited November 25, 20187 yr by NullDrone

Break it down into small manageable tasks, ask for help, Google etc.

2 hours ago, rbrtsmith said:

Break it down into small manageable tasks, ask for help, Google etc.

Basically this. You have to break something you don't know into the smallest possible set of tasks, and tackle each one individually. TDD is pretty good for this. You're often testing in isolation, so you're not really concerned about the entire app all at once. Instead you can focus on smaller, manageable units of code, and smaller features. Trying to keep everything in your head is problematic, there are too many things you won't consider as part of the build or test phase.
 

3 hours ago, Jack said:

Basically this. You have to break something you don't know into the smallest possible set of tasks, and tackle each one individually. TDD is pretty good for this. You're often testing in isolation, so you're not really concerned about the entire app all at once. Instead you can focus on smaller, manageable units of code, and smaller features. Trying to keep everything in your head is problematic, there are too many things you won't consider as part of the build or test phase.
 

Talking of testing myself and Paul are doing a lot of work to try and teach people not to test things in complete isolation…If that makes sense!

In that we try and test features as units of behaviour.   See this repo for an example https://github.com/rbrtsmith/react-tdd so my tests are around the behaviours and I don't test each file individually.
That said say with the Redux example above if you are you know a reducer is going to be complex you might want to write some tests for that before implementing it, but once your main tests at the API level go green then the reducer tests have served their purpose and can be deleted.  You wouldn't want them to lie around because then you are tied more closely to the implementation which means changing it is harder.
This is a good talk speaking of what I describe 

OP: Sorry for going off topic, I just have a strong interest in TDD and thought this might be useful for @Jack

The TL;DR: is that if a unit is never run in isolation then there's no benefit to testing that way because it's not representative of reality - you could end up testing edge-cases that would never arise.

Edited November 26, 20187 yr by rbrtsmith

14 minutes ago, rbrtsmith said:

Talking of testing myself and Paul are doing a lot of work to try and teach people not to test things in complete isolation…If that makes sense!

In that we try and test features as units of behaviour.   See this repo for an example https://github.com/rbrtsmith/react-tdd so my tests are around the behaviours and I don't test each file individually.
That said say with the Redux example above if you are you know a reducer is going to be complex you might want to write some tests for that before implementing it, but once your main tests at the API level go green then the reducer tests have served their purpose and can be deleted.  You wouldn't want them to lie around because then you are tied more closely to the implementation which means changing it is harder.
This is a good talk speaking of what I describe 

OP: Sorry for going off topic, I just have a strong interest in TDD and thought this might be useful for @Jack

The TL;DR: is that if a unit is never run in isolation then there's no benefit to testing that way because it's not representative of reality - you could end up testing edge-cases that would never arise.

The mainly integration over unit approach seems fine, but some things in UI testing I still think are a bad idea at a glance. For example, testing specific text values and class / attribute names, your tests will need to be refactored with any component re-design. I don't know a way around it, I guess you could test less specific values, and do string.includes('remove') or something, but that's not ideal either.

I'll take a look at that video, we probably need to get the TDD thread back up and running at some point.

On 11/26/2018 at 2:12 PM, Jack said:

The mainly integration over unit approach seems fine, but some things in UI testing I still think are a bad idea at a glance. For example, testing specific text values and class / attribute names, your tests will need to be refactored with any component re-design. I don't know a way around it, I guess you could test less specific values, and do string.includes('remove') or something, but that's not ideal either.

I'll take a look at that video, we probably need to get the TDD thread back up and running at some point.

So I don't ever use classNames for test-hooks because as you say they are open to change.  We use `data-test-id` at Sky and have a Babel plugin to strip them out in production.  As for text, if it is static I don't test, in fact we never test static values.  Only behaviours and don't consider something that is static to be a behaviour. 
Most of the text comes from a headless CMS or it's merged with data from another service so the tests will never be flaky with that because we pass in the text as part of the data/fixture for the corresponding text.
The above works really well for the test-first approach (which is required for TDD) because while you might not know what the markup will look like, you can determine ahead of time critical elements for a story based on the design.  A basket will have a list of products with images, prices, a total price and a checkout button (perhaps some remove or add more buttons too).  You can determine what these `data-test-ids` are and write your tests, make them go green before you start adding in extra <divs> and classnames etc for styling.
Of course if a className is added conditionally I will test for it's existence.

I should add that these kind of tests are wrongly labeled as integration tests - even Kent Dodds agreed when I asked him personally but for some reason the community has adopted that description for this kind of test so Kent went along with it.
If you watch the video it goes into detail about what a unit test and int test actually is - an int test is a test that tests the integration between different services - so your app and various APIs - not a collection of components.
A unit test is not depicted by a test that only hits a single file or module, it's a test that can run in complete isolation of other tests, the module under test may well import other modules as part of it's dependency tree and they should not be mocked unless they are slow (An Animation library or XHR call for example).  I'd love to know where it all went wrong.  If you read the work by Kent Beck (Guy who originally documented TDD) this is how it was described but somehow people have misinterpreted it.

It's a shame Paul can no longer post on here because he's been testing this way for years and working with him for the past year has been quite enlightening.  Since adopting this way of testing my UI tests are far more stable and I can refactor with ease.

For example I had some local React state in a component around our checkout process, everything was tested in the way I describe above.  It was decided that some other routes needed access to this state.  We were able to move that state out into Redux, and because the behaviour for the checkout hadn't changed we didn't even need to touch the tests - they went red until the refactor was done at which point they went green, it was great to demo this process to the others.

There are times when you may want to test something like a Reducer in isolation - if it's complexity warrants it.  I say this because it's an implementation detail, and testing those directly comes at a cost - in that you get more tightly bound to how the feature is implemented, this makes refactoring harder to do, if you change a test you no longer have full confidence that your work hasn't caused a regression.  However that cost is sometimes worth it if the function is of enough complexity that the test that is documenting it is worth the cost.
I sometimes write these sorts of tests to help with building out implementation details but they usually get deleted when the main unit tests go green.

Edited November 28, 20187 yr by rbrtsmith