New answers tagged

3

To be pedantic, nothing in the Agile Manifesto or the Scrum Guide make any reference to technical practices, like unit testing or TDD, at all. So, yes, in theory you could deliver early and often with a focus on collaboration and value without them and call yourself agile. In practice however, it's nearly impossible to consistently deliver value (into ...


7

The agile manifesto simply states: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan No mention of unit tests there. Even the 12 principles do not mention testing. So, technically, it's possible to be an ...


4

Make sure you review Uncle Bob's recent comments about the role of design in TDD. Domain-driven design involves a lot of technical patterns, defining well established layers like Application layer, Infrastructure layer, Domain Layer, Persistence layer. Udi Dahan: "God, how I hate layering." He spends some time discussing it in his talk CQRS - but ...


4

Test Driven Development (TDD) is not a design. It's a requirement that impacts your design. Just as if you were required to be thread safe, that's not a design. Again, it's a requirement that impacts your design. If you gleefully ignore all other design concerns and religiously keep to the TDD rules don't blame TDD when your code turns into crap. It ...


1

TDD insures your code has all necessary test cases written in parallel to development. This shouldn't effect high level design. Think of it more in the trenches work. DDD is all about high level designs, language between domain experts & engineers, context mapping, etc. This should be the driver of the application high level design. These are both ...


0

It's a little hard to answer in general, but I think you should consider TDD to be the more overarching approach. Until you have examples that show a design simpler than DDD won't work, you should stick with the simpler design.


0

Just as unit testing Java or Javascript means writing unit tests using the Java language for java, and unit testing Javascript functions with Javascript, writing automated tests to drive you to write stored procedures mean the unit test library you're looking for is based on stored procedures. Said another way, use stored procedures to test stored ...


2

One thing to always try to remember is that we're now using CODE REPOSITORIES with VERSION CONTROL. That deleted code isn't actually gone...it's still there somewhere in a previous iteration. So blow it away! Be liberal with the delete key, because you can always go back and retrieve that precious elegant method that you thought might be useful ...


2

It's desirable to remove b() once it's no longer used, for the same reason that it's desirable not to add un-used functions in the first place. Whether you call it "readability" or something else, all else being equal it's an improvement to the code that it doesn't contain anything it has no use for. For the sake of having at least one specific measure by ...


26

Removing a public method is not "refactoring" -- refactoring is changing the implementation while continuing to pass existing tests. However, removing an unneeded method is a perfectly reasonable design change. TDD draws this out to some extent, because in reviewing the tests, you may observe that it's testing an unneeded method. The tests are driving your ...


9

In fact f() replaces all calls to b() with the exception of the unit tests that defined / described b() IMHO the typical TDD cycle will look like this: write failing tests for f() (probably based on the tests for b()): tests go red implement f() -> tests become green refactor: -> remove b() and all tests for b() For the last step, you might consider ...


4

Yes, it is. The best, most bug-free, most readable code is the code that doesn't exist. Strive to write as much non-code as possible while fulfilling your requirements.


17

Yes, of course. The easiest code to read is that which isn't there. That said, refactoring generally means improving the code without changing its behavior. If you think of something that improves the code, just do it. There's no need to fit it into some pigeon hole before you're allowed to do it.


1

Your update asks is this sufficient to test your scenario: _officerManager.UpdateHissOfficersFromConfirm(); _sourceRepository.Verify(mock => mock.GetAllActiveOfficers(), Times.Once()); _targetRepository.Verify(mock => mock.Add(It.IsAny<List<Officer>>()), Times.Once()); Ultimately it's up to you, however I wouldn't be happy with it as a ...


0

There is nothing complicated here. You just need to check if side-effect happened. Pseudocode: PreviousOfficers = _targetRepository.GetAllOfficers() UpdateHissOfficersFromSource() NewOfficers = _targetRepository.GetAllOfficers() AddedOfficers = NewOfficers except PreviousOfficers ActiveOfficers = _sourceRepository.GetAllActiveOfficers() ...


5

Do you inject the target repository (i.e. are you using dependency injection) If so, you should be able to assert that _targetRepository.Add(officers) is called by querying your mocked target repository. This is a common problem and pattern for a solution in testing. Dependency injection helps you solve this since your test can provide the mocked ...


-1

Why not return the List instead of void and that list to _actionOfficerRepository in the Confirm() method (I don't know what is calling this method). When your return type is the List instead of void it will be much easier to test this + it will be very handy for reusing this method from other actions.



Top 50 recent answers are included