You are separating the application into components horizontally - UI component, backend component and so on.
Instead, you should look at it vertically - what are the different features - it could be login/logout, display list of users, display some other data and so on. Sort those slices into a priority order - which one needs to be done first, which needs to be done second and so on.
Then you concentrate on the most important slice until it works, whatever it takes - if it needs UI you add UI, if it needs backend logic you add backend logic and so on. Only after it is finished and fully working you go back to your list of slices, reevalute them, select the most important one again and concentrate on it.
Repeat until you are done.
This is basically what always working software means.
It allows you to stop at any point and say - this is good enough, and ship it.
If you work horizontally you will not have anything working until you finish all the work.
If you want to do TDD/BDD you do start with tests.
In my humble opinion it is always good to start with model tests unless they are totally based on framework's functionality.
As for checking Controller/View part I prefer to have 'blackbox' tests which check if i get response I expect from an http request (for web applications). It allows to remove brittleness from the tests.
Even if I do full TDD test I often throw tests away if they are about nitty gritty parts of implementation, because otherwise very when refactor implementation at the end user experience is the same, so my application works fine, but I am spending hours fixing the tests. I don't to train myself to avoid refactoring just because I know the pain it would give by redoing a large body of testing code.
I would advice to test only things that really matter to you and ignore the rest till it bites.
When I do get a bug from something I was ignoring, I do write a test to document the bug even it it is about low level implementation.
发布评论
评论（3）
你从错误的角度看待它。
您将应用程序水平分成组件 - UI 组件、后端组件等。
相反，您应该垂直查看它 - 有哪些不同的功能 - 它可以是登录/注销、显示用户列表、显示一些其他数据等等。将这些切片按优先级顺序排序 - 哪个需要首先完成，哪个需要其次完成，依此类推。
然后，您专注于最重要的部分，直到它起作用为止，无论需要什么 - 如果它需要 UI，您就添加 UI，如果它需要后端逻辑，您就添加后端逻辑，等等。只有在它完成并完全工作后，您才能返回切片列表，重新评估它们，再次选择最重要的一个并专注于它。
重复直到完成。
这基本上就是始终工作的软件的含义。
它允许您在任何时候停下来说 - 这已经足够好了，然后发货。
如果您水平工作，那么在完成所有工作之前，您将不会有任何工作。
You are looking at it from a wrong perspective.
You are separating the application into components horizontally - UI component, backend component and so on.
Instead, you should look at it vertically - what are the different features - it could be login/logout, display list of users, display some other data and so on. Sort those slices into a priority order - which one needs to be done first, which needs to be done second and so on.
Then you concentrate on the most important slice until it works, whatever it takes - if it needs UI you add UI, if it needs backend logic you add backend logic and so on. Only after it is finished and fully working you go back to your list of slices, reevalute them, select the most important one again and concentrate on it.
Repeat until you are done.
This is basically what always working software means.
It allows you to stop at any point and say - this is good enough, and ship it.
If you work horizontally you will not have anything working until you finish all the work.
我通常从最重要的功能和区域开始。看看这个答案。
I usually start with the feature and area that is most important. Take a look at this SO answer.
如果你想做 TDD/BDD，你就从测试开始。
以我的愚见，从模型测试开始总是好的，除非它们完全基于框架的功能。
至于检查控制器/视图部分，我更喜欢进行“黑盒”测试，检查我是否从 http 请求（对于 Web 应用程序）中获得了我期望的响应。它可以消除测试中的脆性。
即使我进行了完整的 TDD 测试，如果测试与实现的具体部分有关，我也会经常丢弃测试，因为否则最终用户体验的重构实现是相同的，所以我的应用程序工作正常，但我花了几个小时来修复测试。我不会训练自己避免重构，只是因为我知道重做大量测试代码会带来痛苦。
我建议只测试对你来说真正重要的事情，而忽略其余的事情，直到它起作用为止。
当我确实从我忽略的东西中发现错误时，我会编写一个测试来记录该错误，即使它是关于低级实现的。
If you want to do TDD/BDD you do start with tests.
In my humble opinion it is always good to start with model tests unless they are totally based on framework's functionality.
As for checking Controller/View part I prefer to have 'blackbox' tests which check if i get response I expect from an http request (for web applications). It allows to remove brittleness from the tests.
Even if I do full TDD test I often throw tests away if they are about nitty gritty parts of implementation, because otherwise very when refactor implementation at the end user experience is the same, so my application works fine, but I am spending hours fixing the tests. I don't to train myself to avoid refactoring just because I know the pain it would give by redoing a large body of testing code.
I would advice to test only things that really matter to you and ignore the rest till it bites.
When I do get a bug from something I was ignoring, I do write a test to document the bug even it it is about low level implementation.