#test-driven-development

What we did:

Test Driven Development. Ruby and rails uses a specific library, or framework called rspec which helps you test out new features as you go along on your project. 

Imagine you’re hemming a jacket piece by piece. Each piece of the jacket needs to fit exactly to the person you’re hemming it for, therefore you need to have them to fit it each time you make a change or hem an additional sleeve. It’d be tedious to call the person each time to come over for a fitting each time right? TDD is like creating the jacket and the mannequin at the same time. The mannequin makes sure the the jacket fits, and the jacket is able to adjust to the mannequin if there are any additional pieces added. 

After lecture was our project for the day, which is poker. While I’m not a poker player, I’ve recently become intrigued by the numbers, strategy of poker, I even watched several hours of videos on Youtube to see what the pros do! While setting up a game of poker with several players has gotten somewhat easier, the main meat of the project was figuring out the poker logic of which 5 card hand beats which 5 card hand. 

I’ve ordered the algorithm by the best hands in terms of Royal flush, straight flush, four of a kind, etc... and assigned a numerical value for each type of hand, now it’s time to figure out how to get those tiebreakers.

Topics where I struggled:

algorithms. Seems like everyone else can whip up an ai quickly out of the air, while I need to picture all the pieces of it on pen and paper. 

Felt a lot more improved:

Practice assessment taking. Maybe it’s because of all the hours spent working on classes and instance variables but I’m starting to understand how classes and methods access each other in Ruby. 

Code that == Mind Blown!

instance_variable_set(arg) - Allows you to access private methods from a class even though they’re specifically set in private! Although not typically recommended, 

How I’m feeling:

Maybe it’s because the midweek but I feel like I’m still able to code or practice for another 3 hours tonight. Will certainly crash this weekend.

6/10 motivation

Code Music

https://www.mixcloud.com/Mike_AD/late-night-alumni-the-122-130bpm-selection/

Sidenote:

I feel like I’ve been ignoring other aspects of my life as I basically devote a majority of my time to a/A. For example, I haven’t clipped my nails this week, or even had time to check the blogs I usually go to! Please read and update me:

www.millionmilesecrets.com

www.thepointsguy.com

Checkout my projects!

https://github.com/theRealYoshi

I’m taking suggestions!

Interesting quotes:

Meszaros uses the term Test Doubleas the generic term for any kind of pretend object used in place of a real object for testing purposes. The name comes from the notion of a Stunt Double in movies. (One of his aims was to avoid using any name that was already widely used.) Meszaros then defined four particular kinds of double:

Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.

Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (anin memory databaseis a good example).

Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'.

Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

[...]

With classic TDD, you have to create not just the SUT but also all the collaborators that the SUT needs in response to the test. [...] Usually these objects are created and torn down with each run of the tests.

Mockist tests, however, only need to create the SUT and mocks for its immediate neighbors. This can avoid some of the involved work in building up complex fixtures (At least in theory. I've come across tales of pretty complex mock setups, but that may be due to not using the tools well.)

In practice, classic testers tend to reuse complex fixtures as much as possible. In the simplest way you do this by putting fixture setup code into the xUnit setup method. More complicated fixtures need to be used by several test classes, so in this case you create special fixture generation classes. 

[...]

If you introduce a bug to a system with mockist testing, it will usually cause only tests whose SUT contains the bug to fail. With the classic approach, however, any tests of client objects can also fail, which leads to failures where the buggy object is used as a collaborator in another object's test. As a result a failure in a highly used object causes a ripple of failing tests all across the system.

Mockist testers consider this to be a major issue; it results in a lot of debugging in order to find the root of the error and fix it. However classicists don't express this as a source of problems. Usually the culprit is relatively easy to spot by looking at which tests fail and the developers can tell that other failures are derived from the root fault. Furthermore if you are testing regularly (as you should) then you know the breakage was caused by what you last edited, so it's not difficult to find the fault.

[...]

In essence classic xunit tests are not just unit tests, but also mini-integration tests. As a result many people like the fact that client tests may catch errors that the main tests for an object may have missed, particularly probing areas where classes interact. Mockist tests lose that quality. In addition you also run the risk that expectations on mockist tests can be incorrect, resulting in unit tests that run green but mask inherent errors.

[...]

When you write a mockist test, you are testing the outbound calls of the SUT to ensure it talks properly to its suppliers. A classic test only cares about the final state - not how that state was derived. Mockist tests are thus more coupled to the implementation of a method. Changing the nature of calls to collaborators usually cause a mockist test to break.

This coupling leads to a couple of concerns. The most important one is the effect on Test Driven Development. With mockist testing, writing the test makes you think about the implementation of the behavior - indeed mockist testers see this as an advantage. Classicists, however, think that it's important to only think about what happens from the external interface and to leave all consideration of implementation until after you're done writing the test.

Coupling to the implementation also interferes with refactoring, since implementation changes are much more likely to break tests than with classic testing.

I hate Testing Frameworks. Actually, let me be specific…I hate .NET Testing Frameworks. They make me angry and sad; so I've decided that because I have nothing better to do, I'll write my own. But first, a little comparison...

VS2010 Testing Framework (MSTest?)

Microsoft’s built in testing system isn’t too bad. It's integration is done well, but it’s so bloody overly complicated and slow, and messy. Every test you perform dumps a shit-load of messy files everywhere on your filesystem and inside your solution folder. It then has the CHEEK to complain that you should delete some when it gets “full”?

Poor effort Bill (or is it Steve now?)

NUnit

As far as I’ve ever been able to tell, this is simply a big, even more bloated version of the above. Some of the testing functionality is simpler and easier to understand, and it does have more assertions…that’s where the good things end. Like a lot of software, it’s probably the most used? Weird that.

xUnit

Made by the same blokes as the above, but apparently it’s better and easier to use. I went over their comparison table they’ve got up on their Codeplex site….yeah, no. If anything, it’s a massive excercise in how to complicate a piece of supposedly useful software even further. I mean…test methods are called “Facts”? Not only that, the method to actually get testing is beyond annoying.

Getting there…but not quite.

Should...

I’m tired. I like ruby, I like libraries like “shoulda” and “cucumber”. You just want to test whether that function does what you want it to; does it fulfil the requirements? Does it do what you expected it to do? I got tired of fumbling around the above libraries. I wanted a simple, easy to use, easy to understand testing framework so that I could test Nucleo quickly and effectively, so I created “Should”. At least that’s what It’s called at the moment.

Creating a test involves (at the moment) two things:

A ShouldTestContext<T> object. Think of it as the manager for all your tests. The generic type parameter <T> is the object you want to perform tests on, or the “context”.

One or more Expectation objects. An expectation test is exactly that; it tests an expectation of something else.

Once you’ve set up all your expectation tests, you make a call to the ShouldTestContext<T>.RealiseExpectations() method and shazzam, it tests away!

Expectation Test Syntax

I wanted to make writing the actual tests as easy as possible; plain english if i could. Turns out I could:

Expectation ex = new Expectation(() = { return true; }, "should return true");

Here, I’ve created a new expectation test and fed it a lambda expression as a delegate that simply returns true (for demo purposes) and my expectation (logically) is that it “should return true”. Using a simple parser, an Expectation is then created by analysing the logic of the expectation string. The parser determines the type of test by what kind of type is passed to it (method, property, field etc.) and then runs a test against the object based on the given expectation. The kind of tests you can run are all your usual suspects, and I may add a few more in the future. Here are some examples of some expectation test strings:

"should contain 'Hello'" (test a collection, array or string) "shouldalways return true" (test a constant) "shouldnot have length > 10" (test a property or field)

The important thing to note is that, underlying all of this is the same basic usage of assertions. It’s the way in which those assertions are performed which is the cool thing. I am also making it completely programmatic too, so if you want to write your tests in the standard way, you still can, and they’ll still be beautiful:

Here is a quick tip:

When a bug is found, DO NOT, run off to fix the bug immediately. Instead, I urge you to write a unit/acceptance test first which exposes the bug. Then and only then, should you go and fix the bug.

By following this mantra you can ensure that all bugs which have appeared in your system are documented by specifications (tests) which prove that they no longer exist.

Here is a quick example. Sally system user reports that the Change E-mail Address feature is saving data in the database replacing the @ symbol with %40. This is causing serious problems and she has requested an urgent fix be provided.

First, identify and simulate the problem (i.e. - get your app up and try to change e-mail address, step through the execution and try to pinpoint where the issue exists).

Next, automate your simulation steps through test (Unit testing, front-end testing using Selenium, WaitR/N, White... whatever it takes to simulate the users experience of entering an e-mail address and producing a record in the database containing %40 instead of @).

Now, add a verification exposing the issue (query the database for your record and verify/assert that the e-mail address does not contain %40). This test should FAIL right now (you haven't gone ahead and fixed the issue already, have you?).

Lastly, go ahead and fix the issue then re-run the test. Once the issue has been resolved your test should pass.

Do your best to refactor the tests such that they align with the features behavior as opposed to its representation (i.e. if you are testing a web page, try not to rely on an elements position in the html tree as these can be volatile and are subject to change when rearranging the look and feel of the page, but normally will not change the way it behaves).

If you are using continuous integration and your build/deployment pipeline executes theses tests, your build should fail in the event that issue reoccur.

I was really pleased to hear Scott Belware’s recent interview (TDD – The Final Word) on Scott Hansleman’s podcast – Hansleminutes. Scott B was really adamant about explaining that TDD is an activity that is focused on design as opposed to testing. He mentions the term Behavior Driven Development (BDD) and how it would be better suited since the word Test in TDD is often the source of confusion. I’m happy that he went as far as to have an entire interview dedicated to changing this common misconception about TDD. Test-Driven Development/Design is not about testing, it’s all about driving out the design of our applications.

Without a strong continuous integration process, a well organized Agile/Scrum project can quickly turn to chaos. Agile is most commonly associated with iterative development, which in turn, implies continuous visibility of a project (Scrum Masters, Product Owners and Stakeholders are always interested in the state of a project) and continuous integration via build automation supply the the foundation for supporting the demanding pace of an Agile/Scrum project.

When I’m developing code on a team, its nice to know that at the very least, the code compiles, unit tests/specifications are passing, the code is well covered and that when I check it in, everyone in the organization who is interested in the state of a project can easily get access to it.

Currently, I am using a set of crafty NAnt scripts along with Team City to ensure the visibility of our project and its associated artifacts.

The NAnt build scripts include features which can compile, execute automated tests/specifications and generate reports, generate code coverage reports, generate code analysis reports, version, create environment specific versions (DEV, QA, PROD, etc), zip the output and back it up to network drive, deploy the the target applications (in my case, web applications) to an integration server for immediate availability as well as an assortment of other things.

Team City listens for check-ins to occur on my source control repository and when it detects one, it grabs the latest version of code and executes the associated NAnt build script. All of the reports generated by the build are visible through the Team City web site interface as well as access to the final build output along with some custom reports that I generate to make it easy to track all of the applications which were affected during the build (paths to generated output, version numbers which were deployed to integration server, etc).

All in all, the combination of a Source Control Repository, NAnt and Team City provide a simple continuous integration solution with valuable information about the latest version of an emerging project.