When i was developing a console app the algorithm was the following steps:

  1. first create a temporary directory
  2. then call another command that will create an xml file inside the the temporary directory
  3. then read that xml file and extract a name from it
  4. lastly rename this temp directory to the name extracted from xml

then i use TDD from outside in and start writing Acceptance test. but i'm still confused what to test.

  1. Do i need to test each step of the above i.e to test if a temp file is created or not then to test what happens if IO Exception occurs, then to test if running the other command produce an xml then test if xml contain an attribute "name" etc.
  2. Or to test if after running the console app a folder is created with an xml only?
  3. how to organize my test suite if i'm going to test my algorithm step by step
  • please don't cross-post: stackoverflow.com/questions/50376576/… "Cross-posting is frowned upon as it leads to fragmented answers splattered all over the network..." – gnat May 16 '18 at 18:51
  • Do you understand that TDD means writing the test before the implementation? – Philip Kendall May 16 '18 at 18:52
  • yes i understand that well, as i follow outside in approach i first write an acceptance test that validate a folder name and xml file inside created when run command, i write production code that make my test pass. – Mostafa Darwish May 16 '18 at 18:56
  • The short answer to your question is that a test embodies a requirement. Unit tests don't test implementation details; they test behavior. – Robert Harvey May 16 '18 at 20:16

To my mind, you have 2 dependencies there: IO and XML. Thereby, you can have 2 interfaces for those components injected into your main app. With this, you can fake the dependencies and create unit tests for your main app. Once you have develop the functionality, you can create integration or acceptance tests about the whole system.

To sum up, what I do when I TDD:

  1. Failing unit test.
  2. Production code
  3. If something is missing, get back to point 1.
  4. Write integration/acceptance/e2e tests.
  5. If you have to change production code, get back to point 1.

Disclosure: I don't have too much experience in TDD yet.

  • good point, here you use the inside out approach. since i have no idea about the design yet so i start with outside in approach, i.e. write acceptance test first. actually i prefer this approach as it's more pragmatic and enforce me to implement early. but as test is all about behavior, then surly to test output structure (a directory + xml) as positive case. but what about IO error? do i need to test IO error? this is considered an implementation detail but at the same time it may affect command output behavior by not creating a directory or xml file – Mostafa Darwish May 16 '18 at 21:07
  • The problem with initial acceptance tests is that a lot of stuff can fail (wrong folder, wrong xml format) and you might spend a lot of time trying to find where's the problem. However, if you work piece by piece, there are very few things that can fail at a time. And that doesn't have (almost) anything to do with inside out vs outside in. Since the moment you inject your dependencies as interfaces, you can use fake IO handler that always return good stuff and XML that always returns you the same title in case you want to debug and look how it would look once is done. – A Bravo Dev May 16 '18 at 21:49
  • About errors/exceptions: yes, that's another part of your logic, so you should check in your tests if you are doing the right thing when an exception is thrown (log it, bubble up the exception, create a custom exception with contextual or business-related info, return an specific default object)... – A Bravo Dev May 16 '18 at 21:53
  • so you suggest to test these implementation steps one by one but using fakes and introducing layers of indirection. This means first i create an interface of file system with a method e.g. createTempDirectory and inject it in my main command code then fake it to return what ever condition to fulfill my test. true? – Mostafa Darwish May 16 '18 at 22:18
  • Exactly. Dealing with files and formats is not always easy, so it's better to forget about it as much as possible. I'm also assuming that you've already moved your main code (where you had the four steps) to a service/manager/whatever related with your business (i. e. OrderService, BasketManager... ) instead of having them right in the main class of the console app... is that true? – A Bravo Dev May 16 '18 at 22:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.